Invoice generation method, device, and storage medium

Abstract

Embodiments of the present application provide a kind of bill generation method, device, equipment and storage medium, the method comprises: obtaining the bill creation request initiated by business system;According to the business type in bill creation request, originating node and target node, the transaction link corresponding to each of multiple transactions is filtered, and target transaction link is obtained;Receive the transaction link acquisition request sent by business system, and transaction link acquisition request is used to obtain target transaction link;Obtain the target business bill created by business system based on transaction subject information and the transaction link identification of target transaction link;According to the identification of commodity in target business bill and the pricing strategy corresponding to target transaction link, the price of commodity in target business bill is obtained, and the financial tax bill corresponding to target business bill is generated.The embodiments of the present application can solve the problem of low efficiency of financial tax bill generation, realize the automatic matching of transaction link and the efficient generation of financial tax bill.

Description

Technical Field

[0001] This application relates to the field of enterprise digital technology, and in particular to a document generation method, device and storage medium. Background Technology

[0002] With the booming development of the new retail industry, digital operations have become a trend for enterprises, whose operating systems typically encompass multiple legal entities, warehouses, stores, and a vast supplier network. Business scenarios are complex and varied, including but not limited to cross-border transfers, domestic transfers, direct mail from suppliers, and cross-entity settlements. In today's complex business environment, enterprise transaction chains increasingly exhibit characteristics of multiple nodes, multiple entities, and cross-regional operations. For the same type of business, depending on its originating node (such as the shipping warehouse or sales department) and target node (such as the receiving customer or branch office), the underlying transaction entities (responsible entities), pricing strategies, and applicable tax rates often differ significantly.

[0003] In existing technologies, the interaction between business systems and financial and tax systems mainly relies on manual configuration and manual triggering. The business system, pricing process, and financial and tax document generation process are independent of each other. Information transmission relies heavily on manual input, table import and export, etc., which not only increases the workload of staff, but also easily leads to data omissions and input errors, resulting in inaccurate correspondence between business documents and financial and tax documents and low efficiency in generating financial and tax documents. Summary of the Invention

[0004] The main objective of this application is to propose a document generation method, apparatus, electronic device, and storage medium that can solve the problem of low efficiency in the generation of existing financial and tax documents, and realize automated matching of transaction links and efficient generation of financial and tax documents.

[0005] To achieve the above objectives, a first aspect of this application proposes a document generation method, the method comprising: Obtain a document creation request initiated by the business system, wherein the document creation request includes the business type of the transaction, the originating node, and the target node; Based on the business type, the originating node, and the target node, the transaction links corresponding to multiple transactions are filtered to obtain the target transaction links. Each transaction link includes transaction subject information and a transaction link identifier. The transaction link identifier is used to identify a unique transaction link formed by connecting at least two nodes in sequence. The at least two nodes include the originating node and the target node of the transaction. The system receives a transaction link acquisition request sent by the business system. The transaction link acquisition request is used to acquire the transaction subject information and the transaction link identifier of the target transaction link. Obtain the target business document created by the business system based on the transaction entity information and the transaction link identifier of the target transaction link. The target business document includes the identifier of the traded goods and the transaction link corresponding to the target business document. The price of the goods in the target business document is calculated based on the product identifier in the target business document and the pricing strategy corresponding to the target transaction link, and a financial and tax document corresponding to the target business document is generated.

[0006] In some embodiments, the step of filtering the transaction links corresponding to multiple transactions based on the business type, the originating node, and the target node to obtain the target transaction link includes: Based on the business type, the originating node, and the target node, the transaction links corresponding to each of the multiple transactions are filtered to obtain at least one matching transaction link that matches the business type, the originating node, and the target node. If there are multiple matching transaction links, then obtain the priority value corresponding to the transaction link identifier of each of the multiple matching transaction links; The transaction link with the highest priority value is selected as the target transaction link.

[0007] In some embodiments, the business types include supplier direct mail business, physical warehouse business and store business. The supplier direct mail business refers to the business in which the supplier, as the originating node, directly sends goods to the warehouse or store. The physical warehouse business refers to the business in which the physical warehouse, as the originating node or the target node, is used. The store business refers to the business in which the store, as the target node, is used. The step of filtering the transaction links corresponding to multiple transactions based on the business type, the originating node, and the target node to obtain the target transaction link includes: If no matching transaction link is found that matches the business type, the originating node, and the target node, then it is determined whether the business type in the document creation request belongs to the supplier direct mail business. If the business type in the document creation request belongs to the supplier direct mail business, then the originating node is configured to all suppliers, and the corresponding first default transaction link is matched based on the originating node; If the business type in the document creation request does not belong to the supplier direct mail business, then obtain the transaction entity information, delivery node and receiving node corresponding to the physical warehouse business or the store business. Based on the transaction entity information, the shipping node, and the receiving node, a corresponding second default transaction link is matched.

[0008] In some embodiments, after obtaining the target business document created by the business system based on the transaction entity information and the transaction link identifier of the target transaction link, and before calculating the price of the goods in the target business document according to the product identifier in the target business document and the pricing strategy corresponding to the target transaction link, and before generating the financial and tax documents corresponding to the target business document, the method further includes: If a node with a pre-configured control type is detected in the target transaction link, the node type of each node in the target transaction link is obtained. The node type includes the shipping node type, receiving node type, import node type and export node type. The control type includes the inbound control type and the outbound control type. The nodes are verified according to their arrangement order in the target transaction link. If there is a node configured as outbound in-transit control type after the node of the shipping node type or the export node type, then the first node configured as outbound in-transit control type in the target transaction link is determined as the in-transit control subject. If the target transaction link includes nodes of the export node type, and the receiving node type has enabled the inbound control type, and no other inbound control node type is set between the export node type node and the receiving node type node, then the control type assigned to each node in the target transaction link is saved.

[0009] In some embodiments, the step of calculating the price of the goods in the target business document based on the product identifier in the target business document and the pricing strategy corresponding to the target transaction link, and generating a financial and tax document corresponding to the target business document, includes: Obtain the transaction layers contained in the target transaction chain, as well as the upstream and downstream nodes of each transaction layer; For each transaction level, if the transaction type of the transaction level is a local currency transaction, then the currency of the upstream node is used as the transaction currency. The sales price of each commodity is calculated in the currency of the upstream node according to the pricing strategy corresponding to the transaction level in the target transaction chain. Then, a financial and tax document corresponding to the transaction of the transaction level is generated at the downstream node of the transaction level. The financial and tax document contains the sales price and the corresponding financial and tax information. Each transaction level corresponds to a pricing strategy. The pricing strategy includes at least one calculation factor. The calculation factor is various basic data used to participate in the price calculation. For each transaction level, if the transaction type of the transaction level is a non-fiduciary currency transaction, then a preset standard currency is used as the transaction currency. The sales price of each commodity denominated in the standard currency is calculated according to the pricing strategy corresponding to the transaction level in the target transaction chain, and financial and tax documents corresponding to the transaction of the transaction level are generated at the downstream node of the transaction level.

[0010] In some embodiments, before calculating the price of the goods in the target business document based on the product identifier in the target business document and the pricing strategy corresponding to the target transaction link, and generating the financial and tax documents corresponding to the target business document, the method further includes: Obtain a document generation instruction initiated by the business system, and query whether there is a corresponding target financial and tax document record in the preset database based on the business document identifier and transaction link identifier in the document generation instruction. The document generation instruction includes a business document identifier and a transaction link identifier. If the target financial and tax document record exists and the execution status of the target financial and tax document record is successful, then the financial and tax document generation process is terminated.

[0011] In some embodiments, after calculating the price of the goods in the target business document based on the product identifier in the target business document and the pricing strategy corresponding to the target transaction link, and generating the financial and tax documents corresponding to the target business document, the method further includes: Store the financial and tax documents corresponding to the target business document in the database, and create or update the corresponding record status to successful.

[0012] In some embodiments, after filtering the transaction links corresponding to multiple transactions according to the business type, the originating node, and the target node to obtain the target transaction link, before sending the transaction subject information and the transaction link identifier of the target transaction link to the business system, the method further includes: Verify the number and order of nodes in the target transaction chain; There is one and only one shipping node and one receiving node, and the shipping node is located before the receiving node in sequence. If an exit node exists, the exit node is in the order of the import node; If the export node coincides with the shipping node, then the export node and the shipping node share the same node identifier; If the import node and the receiving node coincide, then the import node and the receiving node share the same node identifier.

[0013] To achieve the above objectives, a second aspect of this application provides a document generation apparatus, the apparatus comprising: The first acquisition module is used to acquire document creation requests initiated by the business system, wherein the document creation request includes the business type of the transaction, the originating node, and the target node; The filtering module is used to filter the transaction links corresponding to multiple transactions according to the business type, the originating node and the target node to obtain the target transaction link. Each transaction link includes transaction subject information and transaction link identifier. The transaction link identifier is used to identify a unique transaction link formed by connecting at least two nodes in sequence. The at least two nodes include the originating node and the target node of the transaction. The receiving module is used to receive a transaction link acquisition request sent by the business system. The transaction link acquisition request is used to acquire the transaction subject information and the transaction link identifier of the target transaction link. The second acquisition module is used to acquire the target business document created by the business system based on the transaction entity information and the transaction link identifier of the target transaction link. The target business document includes the identifier of the traded goods and the transaction link corresponding to the target business document. The generation module is used to calculate the price of the goods in the target business document based on the identifier of the goods in the target business document and the pricing strategy corresponding to the target transaction link, and generate the financial and tax documents corresponding to the target business document.

[0014] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect.

[0015] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0016] The document generation method, apparatus, electronic device, and storage medium proposed in this application acquire document creation requests initiated by the business system, including business type, originating node, and target node. Based on this dimensional information, it automatically filters matching target transaction links from a pre-set transaction link library and returns the main information to the business system for business processing. Subsequently, it receives target business documents containing product identifiers from the business system, obtains prices based on the product identifiers, and automatically generates corresponding financial and tax documents in conjunction with the pricing strategy corresponding to the target transaction link. This application achieves automatic linkage between the business system and the financial and tax system, ensuring consistency throughout the entire process of transaction path, pricing calculation, and document generation, effectively improving financial processing efficiency and tax compliance. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the document generation method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the transaction link matching logic provided in the embodiments of this application; Figure 3 This is a schematic diagram of the document generation device provided in the embodiments of this application; Figure 4 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0021] With the booming development of the new retail industry, digital operations have become a trend for enterprises, whose operating systems typically encompass multiple legal entities, warehouses, stores, and a vast supplier network. Business scenarios are complex and varied, including but not limited to cross-border transfers, domestic transfers, direct mail from suppliers, and cross-entity settlements. In today's complex business environment, enterprise transaction chains increasingly exhibit characteristics of multiple nodes, multiple entities, and cross-regional operations. For the same type of business, depending on its originating node (such as the shipping warehouse or sales department) and target node (such as the receiving customer or branch office), the underlying transaction entities (responsible entities), pricing strategies, and applicable tax rates often differ significantly.

[0022] In existing technologies, when a business transaction occurs, the system often cannot automatically identify the transaction path based on the real-time business type and node information, requiring extensive manual configuration, which is inefficient and prone to errors. The interaction between the business system and the financial and tax system mainly relies on manual configuration and manual triggering. The business system, pricing process, and financial and tax document generation process are independent of each other, lacking a unified rule engine to ensure the consistency of transaction paths and tax processing logic, resulting in data asynchrony. Price calculation is often separated from tax calculation, leading to delays or calculation errors in accounting voucher generation, making it difficult to meet financial compliance requirements. In multi-entity transactions, the circulation status of inventory (such as in-transit status) is difficult to track accurately, resulting in inconsistent financial settlement cycles, affecting the company's asset management and financial accounting.

[0023] Based on this, the embodiments of this application provide a document generation method, apparatus, electronic device and storage medium, aiming to provide an intelligent method based on matching rules and link rules. Through intelligent link matching and rule engine, it realizes automatic identification of transaction paths, accurate price calculation and automatic generation of financial and tax documents under multiple subjects and multiple business types. It solves the problems of manual link configuration, fragmented financial and tax processing and difficulties in cross-subject settlement in traditional systems, and improves financial settlement efficiency and tax compliance.

[0024] The document generation method, apparatus, electronic device, and storage medium provided in this application are specifically described through the following embodiments. First, the document generation method in this application is described.

[0025] The document generation method provided in this application relates to the field of enterprise digital technology. The document generation method provided in this application can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the document generation method, but is not limited to the above forms.

[0026] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0027] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

[0028] Figure 1 This is an optional flowchart of the document generation method provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps S100 to S500.

[0029] Step S100: Obtain the document creation request initiated by the business system, wherein the document creation request includes the business type of the transaction, the originating node, and the target node.

[0030] In this embodiment, the document generation method can be applied to the financial and tax cloud system, which is connected to business systems (such as supply chain management systems, SCM) and data warehouses.

[0031] In this embodiment, the business system is responsible for document creation and node information transmission. When the business system creates a document (such as a purchase order or a packing list), it sends a request to the financial and tax cloud platform. This request carries the transaction's business type, the originating node (such as the shipper, warehouse, or supplier), and the target node (such as the recipient, store, or warehouse).

[0032] Specifically, the system pre-sets multiple business types to cover different logistics and capital flow paths. These business types include, but are not limited to: cross-border warehouse-to-warehouse, local warehouse-to-warehouse, cross-border warehouse-to-store, local warehouse-to-store, supplier direct mail to warehouse, and supplier direct mail to store. The originating node identifies the shipper or starting location of the transaction, which can be a physical warehouse code, store code, or supplier code. The destination node identifies the recipient or ending location of the transaction, which can be a physical warehouse code or store code. The originating and destination nodes are matched with the corresponding code type (physical warehouse code, store code, supplier code, etc.) based on the business type. For example, if the business type is "cross-border / local warehouse-to-warehouse," then the originating node is the physical warehouse code, and the destination node is the physical warehouse code; if the business type is "supplier direct mail to store," then the originating node is the supplier code, and the destination node is the store code.

[0033] Step S200: Based on the business type, the originating node, and the target node, filter the transaction links corresponding to each of the multiple transactions to obtain the target transaction links. Each transaction link includes transaction subject information and a transaction link identifier. The transaction link identifier is used to identify a unique transaction link formed by connecting at least two nodes in sequence. The at least two nodes include the originating node and the target node of the transaction.

[0034] In this embodiment, the transaction link matching logic is as follows: Figure 2As shown. The financial and tax cloud system has a built-in matching rule management module and a link rule management module. First, the system determines the constraints of the node type based on the input business type. For example, if the business type is "supplier direct mail to warehouse", the originating node must match the "supplier code" and the target node must match the "physical warehouse code". Second, the system searches the rule base for valid rules based on the originating node and the target node. A valid rule is one that simultaneously satisfies the business type, originating node, target node, and is within its validity period. Third, if multiple matching rules exist, the system further parses the conditional expressions in the rules. Only when the result of the conditional expression is "true" will the transaction link associated with the rule be determined as usable. Finally, if multiple usable transaction links are selected, the system sorts them according to a preset priority mechanism (the higher the priority value, the higher the priority), and determines the transaction link with the highest priority as the target transaction link.

[0035] A target transaction chain defines a complete transaction path, which is formed by connecting at least two nodes in sequence. For example, a typical cross-border transaction chain may include: supplier node → export node (Chinese subsidiary) → import node (Indonesian subsidiary) → receiving node (store).

[0036] Each target transaction link includes a transaction link identifier (link ID) and transaction entity information. The transaction link identifier is a unique code that identifies the transaction path; the transaction entity information refers to the legal entity corresponding to each node in the link (such as the shipper, the recipient, etc.). For example, the shipping node corresponds to: China sales subsidiary A, and the receiving node corresponds to: Indonesian retail subsidiary B.

[0037] In addition, the system also supports fallback logic. For example, for "supplier direct mail" type businesses, if a specific supplier rule cannot be matched, the system will configure a special "all suppliers" filter as a fallback rule, or default to returning the default transaction link corresponding to the purchasing entity to ensure that the process is not interrupted.

[0038] Step S300: Receive a transaction link acquisition request sent by the business system. The transaction link acquisition request is used to acquire the transaction subject information and the transaction link identifier of the target transaction link.

[0039] In this embodiment, the transaction link is obtained by the business system through a request to the tax and finance cloud system based on the originating node and the target node. After receiving the transaction link acquisition request from the business system, the tax and finance cloud system returns the transaction entity information (such as the cargo owner code) and the transaction link ID corresponding to the target transaction link to the business system. After receiving the returned information, the business system checks whether the corresponding cargo owner's inventory is sufficient; writes the cargo owner code and the corresponding link ID to the document; and performs inventory deduction (outbound) or increase (inbound) operations according to priority based on the returned multiple link information (if any).

[0040] Step S400: Obtain the target business document created by the business system based on the transaction entity information and the transaction link identifier of the target transaction link. The target business document includes the identifier of the traded goods and the transaction link corresponding to the target business document.

[0041] In this embodiment, after the business system completes the document creation and inventory operation, the financial and tax cloud system needs to obtain the specific document information to generate financial vouchers. This can be achieved through real-time interface calls or T+1 scheduled tasks to synchronize from the data warehouse.

[0042] The financial and tax cloud system receives the target business documents that have been screened and confirmed by the business system. The target business documents contain: a unique document identifier (document number), a bound transaction link identifier, and the identifier of the traded goods (SKU code set).

[0043] Step S500: Calculate the price of the goods in the target business document based on the product identifier in the target business document and the pricing strategy corresponding to the target transaction link, and generate a financial and tax document corresponding to the target business document.

[0044] In this embodiment, price calculation must be completed before generating financial and tax documents. The financial and tax cloud system calls the price calculation interface based on the transaction link code, document code, and commodity code set.

[0045] Specifically, the tax and finance cloud system first retrieves detailed configuration information for the transaction link from the link rule base based on the transaction link ID on the document. This configuration information defines which nodes the link includes (e.g., shipping node A, export node B, import node C, receiving node D), the type of each node, and the pricing strategy for each transaction level (e.g., A→B, B→C, C→D). Then, the tax and finance cloud system calculates prices based on the SKU set in the target business document and the pricing strategies for each level. The pricing strategy defines calculation factors and formulas. Calculation factors include, but are not limited to: the preferred supplier's purchase price (i.e., the baseline cost of the goods), exchange rate, markup rate, and the tax-exclusive price of the previous transaction link's sales order. For example, a price calculation interface can be called to calculate the transaction price of each SKU at each transaction level using expressions and calculation factors in the pricing strategy. Subsequently, the tax and finance cloud system automatically generates a series of tax and finance documents based on these calculated prices and predefined tax and finance rules, such as internal purchase orders, internal sales orders, goods receipts, and invoices. To ensure consistency in financial settlement cycles, documents for transactions between two parties (e.g., A and B) are generated uniformly at downstream nodes (e.g., node B). Generated document types include purchase orders, goods receipts, invoices, sales orders, goods fulfillment documents, and invoices. Since the process may be executed in stages (e.g., shipping before receiving), the document generation process must guarantee idempotency to prevent duplicate generation. If an in-transit control node is configured in the chain (e.g., the export node after shipment), the system will generate in-transit inventory documents at the corresponding node to achieve real-time tracking of inventory status.

[0046] This embodiment achieves automated screening and matching of transaction chains without manual configuration. It accurately matches target transaction chains based on business type, originating node, and target node, while also implementing a fallback strategy to prevent chain matching failures. It also completes intelligent calculation of commodity prices, automating price calculation based on transaction chain pricing rules and multi-dimensional calculation factors, combined with the base currency / For transactions using non-fidelity currencies, pricing strategies are determined to ensure the accuracy and reasonableness of price calculations. Standardized and regulated generation of financial and tax documents is achieved, generating corresponding documents based on the target transaction chain and target business documents. Documents for transactions at the same level are generated uniformly at downstream nodes, ensuring consistency in the financial settlement cycle. Idempotency processing is required during document generation to avoid duplicate document generation. Full-process data linkage between the business system and the financial and tax cloud system is achieved, with real-time data interaction at each stage from obtaining document creation requests to generating financial and tax documents. This ensures logical consistency between the transaction chain, price calculation, tax processing, and document generation, improving financial reconciliation efficiency and reducing tax compliance risks and manual maintenance costs. It adapts to complex transaction scenarios in the new retail industry, such as cross-border transfers, local transfers, and direct mail from suppliers, supporting transaction chain configurations with multiple legal entities and multiple nodes. A transaction hierarchy and in-transit control mechanism are introduced to synchronize inventory, settlement, and tax status.

[0047] In some embodiments, step S200 may include, but is not limited to, steps S210 to S230: Step S210: Based on the business type, the originating node, and the target node, filter the transaction links corresponding to each of the multiple transactions to obtain at least one matching transaction link that matches the business type, the originating node, and the target node. Step S220: If there are multiple matching transaction links, obtain the priority value corresponding to the transaction link identifier of each of the multiple matching transaction links; Step S230: The transaction link corresponding to the transaction link with the highest priority value is taken as the target transaction link.

[0048] In this embodiment, the financial and tax cloud system has a built-in matching rule management module. When a document creation request is received from a business system, the system first extracts the business type (e.g., "local warehouse to store"), originating node (e.g., "physical warehouse code 01"), and target node (e.g., "store code 02") carried in the request. The system then searches the rule base based on these dimensions. According to the "core matching logic" in the reference information, the system determines whether there are valid rules for the matching dimensions. A valid rule means that the input business type, originating node, target node, and valid time all match the preset rules. If the match is successful, the system further runs the conditional expression associated with the rule. When the expression result is true, the system obtains the set of transaction links associated with the rule as the initially selected "matching transaction links".

[0049] Specifically, transaction link matching scenarios are categorized by logistics path and business type, resulting in 9 core scenarios. Each category requires specifying the associated documents (which documents need to record the link) and the link storage location (which line of details records the link). Specific scenarios are shown in Table 1: Table 1

[0050] The configurable options for the originating node and the target node depend on the service type selected in the rule, and the corresponding relationships are shown in Table 2: Table 2

[0051] In complex real-world business scenarios, especially for large group enterprises involving multiple legal entities and warehouses, multiple legitimate transaction links may exist for the same set of business types, originating nodes, and destination nodes. For example, there might be two paths for goods shipped from an "Indonesian warehouse" to a "Malaysian warehouse": one through "Entity A" for settlement, and the other through "Entity B" for settlement. Both paths are potentially legitimate in the rule configuration. In this case, the system will filter out at least one matching transaction link. The system then sorts the matching transaction links according to a preset sorting rule.

[0052] In this embodiment, if multiple matching transaction links exist, the priority values ​​of each of these candidate links are obtained. These priority values ​​can be preset according to business needs; for example, links with better inventory deduction logic, lower transportation costs, or more convenient financial settlement can be assigned higher priorities. Then, the transaction link with the highest priority value among all candidate links is determined as the target transaction link.

[0053] The logic for link matching and inventory deduction is as follows: The financial cloud returns multiple transaction links, sorted by priority value. During outbound shipment, inventory is deducted from the shipping entity according to priority; during inbound shipment, inventory is added to the receiving entity according to priority. The shipping entity and receiving entity must be recorded as a pair in the detail row.

[0054] For example, if the business scenario involves transferring goods from an "Indonesian warehouse" to a "Malaysian warehouse," involving SKU S1, with a total outbound volume of 40 items, the system filters based on business type (cross-border warehouse to warehouse), originating node (Indonesian warehouse), and destination node (Malaysian warehouse), finding two matching transaction links: Matching transaction link 1: The link ID is Link_A, the path is Indonesian warehouse A (main A) → Malaysian warehouse C (main C), and the configured priority value is first priority (high).

[0055] Matching transaction link 2: The link ID is Link_B, the path is Indonesian warehouse B (main body B) → Malaysian warehouse D (main body D), and the configured priority value is second priority (low).

[0056] The system obtains the priority values ​​of Link_A and Link_B, compares them, and finds that Link_A has a higher priority. The transaction link corresponding to Link_A is then identified as the target transaction link.

[0057] Subsequent inventory deductions and document generation follow the execution of the target transaction chain: Outbound deduction: Inventory will be deducted first from Indonesian warehouse A (assuming A has 30 units of inventory).

[0058] Increased inventory: Prioritize increasing inventory in warehouse C in Malaysia (add 30 units to C).

[0059] Remaining inventory handling: If inventory A is insufficient (e.g., 10 units short), the system will then consider whether to deduct the remaining 10 units from the low-priority Indonesian warehouse B and transfer them to the Malaysian warehouse D, based on priority logic or the configured fallback strategy.

[0060] This embodiment uses a two-layer design of "matching rules" and "link rules" to decouple and link complex business scenarios with standardized financial and tax processing logic. In particular, by introducing a priority value comparison mechanism, it realizes automatic selection of the best among multiple feasible paths, further improving the optimality of transaction path selection and the flexibility of business execution.

[0061] In some embodiments, the business types include supplier direct mail business, physical warehouse business, and store business. Supplier direct mail business refers to business in which the supplier, as the originating node, directly sends goods to the warehouse or store. Physical warehouse business refers to business in which the physical warehouse, as the originating node or the destination node, is used. Store business refers to business in which the store, as the destination node, is used. Step S200 may also include, but is not limited to, steps S240 to S270: Step S240: If no matching transaction link is obtained that matches the business type, the originating node, and the target node, then determine whether the business type in the document creation request belongs to the supplier direct mail business. Step S250: If the business type in the document creation request belongs to the supplier direct mail business, then the originating node is configured to all suppliers, and the corresponding first default transaction link is matched based on the originating node. Step S260: If the business type in the document creation request does not belong to the supplier direct mail business, then obtain the transaction entity information, delivery node and receiving node corresponding to the physical warehouse business or the store business. Step S270: Match the corresponding second default transaction link based on the transaction entity information, the shipping node, and the receiving node.

[0062] In this embodiment, when the system filters according to the business type, the originating node and the target node, and does not obtain at least one matching transaction link that matches all three (i.e., the matching result is empty), a fallback matching logic is introduced.

[0063] The system categorizes business types into three main types: supplier direct mail, physical warehouse, and store-based services. Supplier direct mail refers to scenarios where the supplier acts as the originating point, bypassing internal group warehouses and directly sending goods to designated warehouses or stores; typical examples include "cross-border supplier direct mail to warehouse" and "local supplier direct mail to store." Physical warehouse services are characterized by using internal group warehouses as the originating or destination point; typical scenarios include "cross-border warehouse to warehouse," "local warehouse to warehouse," and "China warehouse to warehouse." Store-based services refer to businesses where goods ultimately flow to stores, i.e., businesses with stores as the destination point; typical scenarios include "cross-border warehouse to store," "local warehouse to store," and "packing orders."

[0064] First, the system checks whether the current business type falls under scenarios involving direct mail from suppliers to warehouses or direct mail from suppliers to stores, where suppliers act as the originating node. In direct mail businesses, groups often have a large number of suppliers (e.g., hundreds or thousands). Configuring a matching rule for each supplier code would result in a huge workload and be difficult to maintain. Therefore, the system has a preset "All Suppliers" filter. When a specific supplier code cannot be matched to a corresponding link, the system automatically switches the originating node from "Specific Supplier Code" to "All Suppliers." Based on this "All Suppliers" node, combined with the target node (warehouse or store) and business type, the system queries the preset default fallback rule to match the first default transaction link. This mechanism greatly reduces manual configuration costs and ensures the availability of the procurement business link.

[0065] When the business type is not supplier direct mail (such as inter-warehouse transfer, warehouse to store, etc.) and the exact rules are not matched, the system needs to perform fallback processing based on the attributes of the node itself. In this case, the type of node involved (physical warehouse or store) is determined, and the corresponding transaction entity information is obtained.

[0066] If the node is a physical warehouse, since the retail system (SCM) typically does not maintain a mapping relationship between warehouses and financial entities, this mapping relationship needs to be maintained independently by the tax and finance cloud system. The system queries the tax and finance cloud database for the financial entity information corresponding to the physical warehouse code.

[0067] If the node is a store, the corresponding entity information is usually maintained by the retail system. The system can call an external interface (such as the "Get Store Information" interface), pass in the store code, and parse the corresponding subsidiary code and other entity information from the data returned by the business system.

[0068] After obtaining the financial entity information (shipper and recipient) corresponding to the warehouse or store, the system combines the shipping and receiving nodes to query the common default transaction link (second default transaction link) in the financial and tax cloud system. For example, the system can return a transaction link with the purchasing entity carried in the business system request as the default consignee (at this time, the transaction link code may be an empty string or a default value), ensuring that business documents can flow normally and generate basic financial and tax vouchers, avoiding process interruption.

[0069] This embodiment classifies business types into supplier direct mail, physical warehouse, and store types, and formulates differentiated fallback matching strategies to achieve full-scenario automated coverage of the transaction chain, avoiding business process interruptions caused by link matching failures, and adapting to all complex transaction scenarios in the new retail industry.

[0070] In some embodiments, after step S400 and before step S500, the steps may include, but are not limited to, the following: If a node with a pre-configured control type is detected in the target transaction link, the node type of each node in the target transaction link is obtained. The node type includes the shipping node type, receiving node type, import node type and export node type. The control type includes the inbound control type and the outbound control type. The nodes are verified according to their arrangement order in the target transaction link. If there is a node configured as outbound in-transit control type after the node of the shipping node type or the export node type, then the first node configured as outbound in-transit control type in the target transaction link is determined as the in-transit control subject. If the target transaction link includes nodes of the export node type, and the receiving node type has enabled the inbound control type, and no other inbound control node type is set between the export node type node and the receiving node type node, then the control type assigned to each node in the target transaction link is saved.

[0071] In this embodiment, in multi-entity transaction chains, especially those involving cross-border transactions or long-chain transfers, there is a time difference in physical displacement between the shipment and receipt of goods. To ensure consistency between financial data and actual inventory status, and to avoid situations where "goods are en route but not recorded in the financial records" or "inventory has been deducted but accounts receivable and payable have not been confirmed," a node-type-based in-transit control mechanism is introduced.

[0072] In this embodiment, the system parses the configuration structure of the target transaction link, identifies all nodes contained in the link, and determines the node type of each node. Based on the definition of the business scenario, node types are mainly divided into the following four categories: Shipment node type: The starting point of the transaction, responsible for shipping the goods.

[0073] Receiving node type: The endpoint of the transaction, responsible for receiving the goods.

[0074] Export node type: This represents the node where goods leave a customs territory and is typically used in cross-border transactions.

[0075] Import node type: Represents the node where goods enter a certain customs territory.

[0076] In-transit control settings can be configured by the user based on the characteristics of the transaction chain, specifying the corresponding in-transit control type for each node. Not every node needs to be configured with an in-transit control type; the node's in-transit control type can be configured, modified, or cleared as needed. When the system detects that a node in the target transaction chain has a pre-configured control type, it verifies the user-configured control type according to preset control rules. The control type determines whether a node is responsible for monitoring the "sent" or "received" status in the transaction chain.

[0077] For receiving nodes, their control type can be set to inbound transit control. This means that the system will track the goods in transit for that segment of the journey before they arrive at the node. For shipping, import, and export nodes, their control type can be set to outbound transit control. This means that the system will track the goods outbound for that segment of the journey after they leave these nodes.

[0078] Separating inbound and outbound transit management allows for scenarios where nodes simultaneously handle both shipping and receiving. For example, in the "factory → transit warehouse → store" chain (A → B → C), transit warehouse B is both a receiving node in the A → B segment and a shipping node in the B → C segment. By assigning different management types, the system can accurately handle both inbound and outbound transit transactions at that node.

[0079] To address the issue of unclear inventory ownership in complex supply chains, the system performs logical verification based on the order of nodes within the target transaction chain to determine the core "in-transit control entity." Specifically, the system checks along the transaction chain's flow, identifying nodes configured for outbound in-transit control after either the shipping or export node type. If such a node exists, the first node configured for outbound in-transit control is identified as the in-transit control entity for that transaction chain. This mechanism is compatible with scenarios where nodes simultaneously act as both shippers and receivers. For example, in the chain A (shipping) → B (transit) → C (receiving), B is both the receiver in the previous segment and the shipper in the next. This rule accurately identifies B as the entity responsible for outbound control in the B → C segment, ensuring consistency between inventory records and actual stock.

[0080] For the specific scenario of cross-border transactions, the system executes specific verification logic. Only when certain conditions are met will the system save the control type assigned to each node in the target transaction chain; otherwise, it will issue an error message prompting the user to adjust the configuration.

[0081] Specifically, if the target transaction chain includes export-type nodes (indicating cross-border business), then the receiving node must have in-transit control enabled. Simultaneously, to ensure clear financial settlement across the cross-border chain, no other in-transit control nodes should be set up between the export node and the receiving node. This is to prevent unclear ownership or confusing tax calculations due to multiple in-transit controls in complex cross-border processes.

[0082] If all the above conditions are met, it indicates that the in-transit control logic of this cross-border link is closed-loop (the exporter controls the outbound shipment, the consignee controls the inbound shipment, and there is no interference in between), and the system will save the current control type configuration. Conversely, if other in-transit control nodes are mixed in between the export and consignee nodes, it may lead to duplicate accounting or status confusion, and the system will refuse to save and prompt for correction.

[0083] This embodiment achieves refined control over the "in transit" status in cross-entity transactions by establishing standardized allocation rules for node types and in-transit control types. By distinguishing between inbound and outbound in-transit status and automatically identifying the in-transit control entity, it ensures that the ownership and status of inventory can be accurately reflected in the financial accounts during the physical flow of goods. This solves the problems of difficulty in tracking cross-entity in-transit inventory and inconsistent financial settlement cycles in traditional systems, and provides a reliable data foundation for the accurate generation of financial and tax documents in the future.

[0084] In some embodiments, step S500 may include, but is not limited to, steps S510 to S530: Step S510: Obtain each transaction level contained in the target transaction chain, as well as the upstream and downstream nodes of each transaction level; Step S520: For each transaction level, if the transaction type of the transaction level is a local currency transaction, then the currency of the upstream node is used as the transaction currency. The sales price of each commodity is calculated in the currency of the upstream node according to the pricing strategy corresponding to the transaction level in the target transaction link. Then, a financial and tax document corresponding to the transaction of the transaction level is generated at the downstream node of the transaction level. The financial and tax document contains the sales price and the corresponding financial and tax information. Each transaction level corresponds to a pricing strategy. The pricing strategy includes at least one calculation factor. The calculation factor is various basic data used to participate in the price calculation. Step S530: For each transaction level, if the transaction type of the transaction level is a non-local currency transaction, then the preset standard currency is used as the transaction currency, and the sales price of each commodity denominated in the standard currency is calculated according to the pricing strategy corresponding to the transaction level in the target transaction link. Then, the financial and tax documents corresponding to the transaction of the transaction level are generated at the downstream node of the transaction level.

[0085] In this embodiment, after receiving a price calculation request, the Finance and Tax Cloud first parses the identified target transaction chain and breaks it down into multiple consecutive transaction levels. Each transaction level represents a transaction relationship between two adjacent entities, including an upstream node (sales subsidiary) and a downstream node (procurement subsidiary).

[0086] Then, the system retrieves the pricing rules for each transaction level from the transaction chain, and calculates the selling price of each product by combining the product code set and the expressions in the pricing rules. The available calculation factors in the expressions are shown in Table 3: Table 3

[0087] In this embodiment, the tax and finance cloud system first obtains all transaction levels contained in the target transaction chain, as well as the upstream and downstream node identifiers corresponding to each transaction level. For each transaction level, the system needs to identify the transaction type of that level, specifically divided into two scenarios: local currency transactions and non-local currency transactions. Local currency transactions refer to transactions where both parties (i.e., upstream and downstream nodes) use the same local currency, usually indicating that both parties are located in the same country or use the same currency for settlement; non-local currency transactions refer to transactions where the two parties use different local currencies, requiring the use of a preset standard currency (such as the US dollar) as the intermediate settlement currency.

[0088] For transactions at the base currency level, the system uses the base currency of the upstream node as the transaction currency for that level and calculates prices according to the preset pricing strategy for that level. The pricing strategy consists of at least one calculation factor and its corresponding calculation expression. The calculation factor is the basic data element participating in the price calculation, such as the preferred supplier purchase price, benchmark price, average supplier purchase price, the price excluding tax on the first purchase order of the month, the price excluding tax on the first inventory adjustment order of the month, the price excluding tax on the sales order of the previous transaction level, and the currency exchange rate. Based on these calculation factors and expressions, the system calculates the sales price of each product at the current level and prices it in the transaction currency. Subsequently, the system generates financial and tax documents corresponding to the transactions at that level on the downstream node side. These documents contain the calculated sales price, tax code, tax rate, and other financial and tax information, such as purchase orders, sales orders, goods receipts, invoices, goods fulfillment orders, and invoices.

[0089] For transactions in non-fiduciary currencies, the system uses a preset standard currency (such as the US dollar) as the transaction currency for that level. It calculates the selling price of each product according to the pricing strategy for that level and prices it in the standard currency. After the calculation is complete, corresponding financial and tax documents are generated on the downstream node side of that level.

[0090] During price calculation, if the original currency of a calculation factor is inconsistent with the trading currency determined at the current trading level, the system needs to perform a currency conversion. Specifically, the system obtains the exchange rate between the original currency and the trading currency of the calculation factor (e.g., a fixed exchange rate between the source currency and the target currency), converts the value of the calculation factor from the original currency to the trading currency, and then substitutes it into the calculation expression to participate in price calculation, thereby ensuring that all values ​​involved in the calculation within the same trading level are measured in the same currency.

[0091] For example, for the transaction chain A (China) → B (Singapore) → C (Indonesia) → D (Indonesia), the product SKU1 has a preferred supplier purchase price of 73, the currency is CNY, the USD to CNY exchange rate is 7.3, and the USD to IDR exchange rate is 2200.

[0092] Phase 1 (A→B): This segment involves a non-local currency transaction (transaction currency is USD). The first node is A, and the second node is B. At this point, the third node does not exist (A has no upstream node). Therefore, the calculation does not use the "sales price excluding tax from the previous transaction link," but instead uses the preferred supplier's purchase price and exchange rate according to preset rules: 73 CNY / 7.3 = 10 USD. The system generates the corresponding financial and tax documents for the A-B transaction at node B, with a sales price of 10 USD.

[0093] Phase 2 (B→C): This phase involves a non-fiduciary currency transaction (the transaction currency is USD). The first node is B, the second node is C, and the third node is A. The system obtains the sales order price excluding tax between the third node A and the first node B (i.e., the 10 USD calculated in Phase 1), and calculates it using a 5% markup: 10 USD × (1 + 0.05) = 10.5 USD. The system generates the corresponding financial and tax documents for the B-C transaction at node C, with a sales price of 10.5 USD.

[0094] Phase 3 (C→D): This phase involves transactions in the base currency (IDR). The first node is C, the second node is D, and the third node is B. The system obtains the sales order price excluding tax between the third node B and the first node C (i.e., the 10.5 USD calculated in Phase 2), and calculates it using the USD to IDR exchange rate of 2200 and a markup of 10%: 10.5 USD × 2200 × (1 + 0.1) = 25,410 IDR. The system generates the corresponding financial and tax documents for the C-D transaction at node D, with a sales price of 25,410 IDR.

[0095] In this embodiment, when generating the financial and tax documents corresponding to the target business document, the price matching logic has already been completed when the document is created in the business system. Therefore, the document generation process theoretically does not need to recalculate the price. The document generation process only handles the shipping, receiving, export, and ordinary nodes. The import node is temporarily treated as an ordinary node. The import node is not involved in the processing because it does not require special processing in the current financial settlement process. The remaining shipping, receiving, and export nodes are all required for financial settlement, and the document generation in the control link is managed. Since finance requires that two documents (here referring to the financial documents required for the same level of transaction be generated in the same period, such as purchase orders, goods receipts, invoices, sales orders, goods fulfillment, and invoices; these six documents are required for the transaction between companies A and B and must be generated and given to finance for settlement within the same settlement period) be generated in the same period, the transactions of both parties are uniformly generated at the downstream node (purchase orders, goods receipts, invoices, sales orders, goods fulfillment, and invoices). For example, in the A→B→C link, the transaction documents between A and B will be generated at node B, including purchase orders, goods receipts, invoices, sales orders, goods fulfillment, and invoices. Similarly, the transaction documents between B and C will be generated at node C.

[0096] Furthermore, the pricing strategy for adjacent nodes involves multiple calculation formulas, with higher priority indicated by their earlier appearance. If the first calculation formula can calculate a price (a price > 0 indicates a calculable price), subsequent formulas are not executed, and the calculated price is used as the tax-exclusive selling price for that transaction segment. Otherwise, other calculation formulas are executed according to their priority. If all calculation formulas fail to calculate a price, the system will display an error message. The AB transaction in link ABC is illustrated below as an example: If the pricing strategy corresponding to transaction A and B includes the following calculation formula: Formula 1: (Price of preferred supplier excluding tax) * 1.1 / USD to RMB.

[0097] Formula 2: (Supplier's average price excluding tax) * 1.1 / USD to RMB.

[0098] Formula 3: (Price of the first purchase order of the month excluding tax) * 1.1 / USD to RMB.

[0099] When calculation formula 1 can calculate the price, segment AB uses that price, and calculation formulas 2 and 3 do not need to be executed.

[0100] If formula 1 cannot calculate the price, continue to use formula 2 to calculate the price; if formula 2 can calculate the price, segment AB uses that price, and formula 3 does not need to be executed.

[0101] This embodiment, through layer-by-layer calculation and unified document generation at downstream nodes, can automatically select the most suitable pricing strategy and calculation factor based on the geographical location, currency differences, and upstream and downstream relationships between nodes in the transaction chain. This enables automated and accurate price calculation in complex cross-border and cross-entity transaction scenarios, ensuring the consistency of prices in upstream and downstream transaction documents and the accuracy of financial data.

[0102] In some embodiments, prior to step S500, the following steps may also be included, but are not limited to: Obtain a document generation instruction initiated by the business system, and query whether there is a corresponding target financial and tax document record in the preset database based on the business document identifier and transaction link identifier in the document generation instruction. The document generation instruction includes a business document identifier and a transaction link identifier. If the target financial and tax document record exists and the execution status of the target financial and tax document record is successful, then the financial and tax document generation process is terminated.

[0103] In this embodiment, considering the complexity of enterprise business scenarios, especially for long-chain transactions that may involve phased execution or where the system may use a T+1 scheduled task for data synchronization and supplementation, an idempotency verification mechanism is introduced before executing the price calculation and document generation logic to avoid generating duplicate financial and tax documents under repeated calls or retry mechanisms, which would lead to chaotic financial data.

[0104] In this embodiment, the financial and tax cloud system receives a trigger signal, which can be a real-time request from the business system or a processing instruction triggered by a T+1 scheduled task after synchronizing data from the data warehouse. The document generation instruction carries key identity information, including a business document identifier (such as a unique document code in the business system) and a transaction link identifier. Based on the above identifier information, the system searches in a locally preset database (or a log table in the data warehouse) to confirm whether the current business document has already undergone a financial and tax document generation operation under the current specific transaction link configuration.

[0105] If the corresponding record does not exist in the database, it means that the business document has not yet been processed for financial and tax purposes, and the system will proceed normally to the subsequent price acquisition and document generation process.

[0106] If a corresponding tax document record already exists in the database, the system will further read the execution status of that record. If the execution status is "successful," it indicates that the tax document for this business transaction has been successfully generated and pushed to the financial system. At this point, the system determines that this is a duplicate request or duplicate trigger. To prevent data duplication, the system directly terminates the current tax document generation process and will not execute subsequent price calculations, document creation, and push operations.

[0107] If the records retrieved from the database show an execution status of "failed" or "processing", the system can perform corresponding exception handling or continue execution according to the preset retry mechanism to ensure that the document is eventually generated successfully.

[0108] This embodiment adds a database pre-processing idempotency verification mechanism before the generation of financial and tax documents. Based on the joint query of business document identifier and transaction link identifier, it achieves accurate verification of the generated financial and tax document records, avoiding the problem of duplicate generation of multiple financial and tax documents corresponding to the same business document from the source. It realizes idempotency control of financial and tax document generation and meets the core requirements of financial settlement for document generation.

[0109] In some embodiments, after step S500, the following steps may also be included, but are not limited to: Store the financial and tax documents corresponding to the target business document in the database, and create or update the corresponding record status to successful.

[0110] In this embodiment, to complete the entire closed loop of tax and financial document generation, ensure the system has full data traceability capabilities, and provide a data foundation for subsequent duplicate request interception, the tax and financial cloud system persistently stores the newly generated tax and financial document data in a preset database after document generation. The data generated by the tax and financial cloud integration is used for financial settlement, including pushing basic information and tax and financial documents to the financial system. During this process, the system not only stores the content of the document itself but also associates and stores related metadata, such as the currently effective link ID, version number, and the price information calculated this time, ensuring that each business transaction has a corresponding electronic financial voucher archive, supporting subsequent T+1 batch synchronization verification and audit traceability.

[0111] After storing the financial and tax documents, the system will create or update the execution record status of the transaction in the database. If the database does not previously contain a record for the transaction document and its associated transaction link, the system will create a new record and mark its status field as "successful". If the corresponding record already exists in the database (for example, if the system recorded a "processing" or "failed" status before the document was generated), the system will update the status of that record to "successful".

[0112] This embodiment ensures that even if the same document is pushed multiple times by the business system, or if the process is executed in stages or nodes are executed repeatedly, the financial and tax cloud system can accurately identify the processing progress and avoid generating duplicate financial vouchers, thereby strictly guaranteeing the rigor and accuracy of the financial settlement process.

[0113] In some embodiments, after step S200 and before step S300, the steps may include, but are not limited to, the following: Verify the number and order of nodes in the target transaction chain; There is one and only one shipping node and one receiving node, and the shipping node is located before the receiving node in sequence. If an exit node exists, the exit node is in the order of the import node; If the export node coincides with the shipping node, then the export node and the shipping node share the same node identifier; If the import node and the receiving node coincide, then the import node and the receiving node share the same node identifier.

[0114] In this embodiment, after the target transaction link is obtained by filtering according to the business type, originating node and target node, in order to ensure that the transaction link conforms to the basic logic of logistics flow and the document generation rules of financial settlement, the system will strictly verify the node structure of the target transaction link before returning the link information to the business system.

[0115] Specifically, the system first parses the node configuration of the target transaction link, verifying the number and order of core nodes. The system checks that there must be exactly one shipping node and exactly one receiving node in the link. This constraint ensures that the transaction has a clear start and end point, avoiding the ambiguity of "many-to-many" or "ownerless shipping." The system verifies that the shipping node must precede the receiving node in the link. This conforms to the basic logic of logistics flow, that is, goods must be sent from the shipper before they can be received by the recipient.

[0116] For transaction chains involving cross-border or customs matters, the system further verifies the relative positions of export and import nodes. If export and import nodes are configured in the target transaction chain, the system must verify that the export node precedes the import node. This rule ensures that the business process conforms to the physical reality of cross-border trade, meaning that goods must complete export customs clearance before entering the destination country and completing import customs clearance.

[0117] In real-world business scenarios, to simplify configuration and adapt to different business models, the system allows certain nodes to overlap in logical or physical locations.

[0118] Export and shipping nodes overlap: In some scenarios (such as factory direct shipments or cross-border warehouse shipments), the physical warehouse for shipment is also the location for export customs declaration. If the verification finds that the export node and the shipping node correspond to the same physical location or legal entity, the system allows this overlap and configures them to share the same node identifier. This means that during data processing, the node performs both shipping and export functions, eliminating the need to create duplicate virtual nodes.

[0119] Import node and receiving node overlap: In some scenarios (such as overseas warehouse inbound), the destination warehouse where the goods arrive directly serves as the import customs clearance location. If the verification finds that the import node and the receiving node correspond to the same location, the system allows this overlap and configures them to share the same node identifier. This means that the node performs both receiving and import functions.

[0120] This embodiment ensures that all transaction links entering the subsequent process comply with the preset business logic and financial and tax requirements by performing structural legality verification immediately after link matching. This eliminates anomalies caused by link configuration errors from the source, thereby ensuring the accuracy and compliance of subsequent financial and tax document generation.

[0121] In some embodiments, a compliant transaction chain model must be constructed before the system performs document generation and matching. This process ensures clear transaction hierarchies among multiple entities, accurate pricing logic, and the absence of logical dead loops.

[0122] The system calls the backend interface to obtain the list of available subsidiaries configured in the transaction link rules, and renders the results to the subsidiary dropdown options in the user interface. When constructing the node hierarchy, if the current node is the first-level node in the transaction link, its pre-subsidiary code (pre_subsidiary_code) is passed as an empty value.

[0123] The user completes the transaction tier configuration on the interface and clicks the "Confirm" button. If the currently configured node is not a first-tier node, the system needs to perform the following operation to obtain the pricing rules: The system calls an API to retrieve inter-company pricing rules. If the API returns multiple pricing rules, the system will display a pop-up for the user to select. After the user selects a rule, the system writes the selected pricing information into the preceding node of the current node. This is because the sales pricing between subsidiaries is determined by the selling subsidiary (i.e., the upstream node), so the pricing rules need to be recorded on the node corresponding to the seller. For example, in the transaction chain "A→B→C", the preceding node of B is A. The pricing rules between A and B will be written into node A, indicating that A needs to calculate the selling price to sell to B according to these rules.

[0124] After the user completes the configuration, the system calls the verification interface to confirm the legality of the link rule hierarchy. The system needs to input all currently configured transaction hierarchy information for verification. The core of link rule hierarchy verification is to prevent loops: taking the transaction link A→B→C as an example, the transaction from A→B is the first level, the transaction from B→C is the second level, and so on. Loops are strictly prohibited in the same transaction link configuration. That is, the next level node of C cannot be any of the nodes preceding C, and in this link, the configurable subsidiary of the next transaction level of C cannot be A or B. If a loop is detected, the system will prompt a configuration error to ensure the directed acyclic nature of the link.

[0125] In a preferred embodiment, the transaction link type is divided into inter-company and external procurement. Inter-company transactions are used to identify transactions between different legal entities (subsidiaries) within a group. This type typically corresponds to scenarios such as internal transfers and distribution, involving internal settlement and transfer pricing. External procurement transactions are used to identify procurement transactions between the group and external suppliers. This type corresponds to the process of purchasing goods from suppliers, involving external accounts payable and procurement cost accounting. When matching transaction links, the system performs a dual screening based on both business type and link type to ensure that different business scenarios are matched with the corresponding transaction links.

[0126] Inter-company link types are applicable to transaction scenarios between different subsidiaries / legal entities within a group, such as cross-border warehouse-to-warehouse, local warehouse-to-store, and intra-group transfers (e.g., goods flow from subsidiary A to subsidiary B). Price calculation adopts the group's internal pricing rules and requires obtaining the inter-company pricing strategy from the hierarchical configuration of the transaction link. The calculation factors prioritize the sales order's price excluding tax and the benchmark price from the previous transaction link, while also combining markup percentages and exchange rates to complete multi-level price accounting, ensuring that internal transaction prices comply with the group's pricing standards.

[0127] The external sourcing link type is applicable to transaction scenarios between the group entity and external suppliers, such as direct mail from suppliers to warehouses / stores, direct overseas sourcing, and local procurement (e.g., goods procurement from external suppliers to group subsidiary warehouses / stores). Price calculation adopts external procurement pricing rules, and the calculation factors prioritize external procurement-related factors such as the preferred supplier's purchase price, the supplier's average purchase price, and the tax-exclusive price of the first purchase order of the month. There is no need to consider internal group markups, and the price is directly linked to the supplier's actual purchase price. In some scenarios, exchange rates are used to complete the price conversion for cross-border procurement.

[0128] Based on the link type of the target transaction link, generate corresponding financial and tax documents according to the corresponding financial and tax processing rules; if the link type is an inter-company link type, generate at least one of internal purchase order, internal sales order, and internal settlement document; if the link type is an external procurement link type, generate at least one of purchase order, goods receipt, and external supplier settlement document.

[0129] This application's embodiments achieve end-to-end automation and intelligence from business occurrence to tax document generation by constructing a two-layer rule engine of "matching rules + link rules" and a corresponding link creation and verification mechanism. This effectively solves the inefficiency and error-prone problems caused by traditional manual configuration. By deeply integrating pricing strategies, tax calculations, and document generation logic, and combining them with an in-transit inventory control mechanism, it ensures a high degree of consistency and real-time synchronization of business flow, cash flow, and tax information, significantly improving financial settlement efficiency and tax compliance, and realizing digital closed-loop management of the entire enterprise's financial and business processes. This application's embodiments solve technical problems such as difficulty in automatically identifying transaction links in multi-entity, multi-scenario scenarios, error-prone link configuration, untrackable in-transit inventory, disconnect between price calculation and document generation, and duplicate document generation, significantly improving financial reconciliation efficiency and tax compliance, and greatly reducing manual maintenance costs.

[0130] Please see Figure 3 This application also provides a document generation device 600, which includes: The first acquisition module 10 is used to acquire a document creation request initiated by the business system, wherein the document creation request includes the business type of the transaction, the originating node and the target node; The filtering module 20 is used to filter the transaction links corresponding to multiple transactions according to the business type, the originating node and the target node to obtain the target transaction link. Each transaction link includes transaction subject information and transaction link identifier. The transaction link identifier is used to identify a unique transaction link formed by connecting at least two nodes in sequence. The at least two nodes include the originating node and the target node of the transaction. The receiving module 30 is used to receive a transaction link acquisition request sent by the business system. The transaction link acquisition request is used to acquire the transaction subject information and the transaction link identifier of the target transaction link. The second acquisition module 40 is used to acquire the target business document created by the business system based on the transaction entity information and the transaction link identifier of the target transaction link. The target business document includes the identifier of the traded goods and the transaction link corresponding to the target business document. The generation module 50 is used to calculate the price of the goods in the target business document based on the identifier of the goods in the target business document and the pricing strategy corresponding to the target transaction link, and generate a financial and tax document corresponding to the target business document.

[0131] In some implementations, the filtering module 20 may include: The first filtering submodule is used to filter the transaction links corresponding to multiple transactions according to the business type, the originating node and the target node, and obtain at least one matching transaction link that matches the business type, the originating node and the target node. The first acquisition submodule is used to acquire the priority value corresponding to the transaction link identifier of each of the multiple matching transaction links if there are multiple matching transaction links. The second filtering submodule is used to select the transaction link corresponding to the transaction link with the highest priority value as the target transaction link.

[0132] In some implementations, the business types include supplier direct mail services, physical warehouse services, and store services. Supplier direct mail services refer to services where the supplier acts as the originating node, directly sending goods to a warehouse or store. Physical warehouse services refer to services where a physical warehouse acts as the originating or destination node. Store services refer to services where a store acts as the destination node. The filtering module 20 may also include: The first judgment submodule is used to determine whether the business type in the document creation request belongs to the supplier direct mail business if at least one matching transaction link that matches the business type, the originating node and the target node is not obtained. The first matching submodule is used to configure the originating node as all suppliers if the business type in the document creation request belongs to the supplier direct mail business, and to match the corresponding first default transaction link based on the originating node. The second judgment submodule is used to obtain the transaction entity information, delivery node and receiving node corresponding to the physical warehouse business or the store business if the business type in the document creation request does not belong to the supplier direct mail business. The second matching submodule is used to match the corresponding second default transaction link based on the transaction entity information, the shipping node, and the receiving node.

[0133] In some embodiments, the document generation device may further include: The third acquisition module is used to acquire the node type of each node in the target transaction link if it is detected that there are nodes with pre-configured control types in the target transaction link. The node types include shipping node type, receiving node type, import node type and export node type, and the control types include inbound in-transit control type and outbound in-transit control type. The first verification module is used to verify the nodes according to their arrangement order in the target transaction link. If there is a node configured as outbound in-transit control type after the node of the shipping node type or the export node type, then the first node configured as outbound in-transit control type in the target transaction link is determined as the in-transit control subject. The storage module is used to store the control type assigned to each node in the target transaction link if the target transaction link includes nodes of the export node type, and nodes of the receiving node type have enabled the inbound control type, and no other inbound control node type nodes are set between the export node type node and the receiving node type node.

[0134] In some implementations, the generation module 50 may include: The second acquisition submodule is used to acquire each transaction level contained in the target transaction link, as well as the upstream and downstream nodes of each transaction level; The first calculation submodule is used to calculate the sales price of each commodity denominated in the currency of the upstream node for each transaction level if the transaction type of the transaction level is a local currency transaction. The calculation is performed according to the pricing strategy corresponding to the transaction level in the target transaction link, and the sales price of each commodity denominated in the currency of the upstream node is obtained. The financial and tax documents corresponding to the transaction of the transaction level are generated at the downstream node of the transaction level. The financial and tax documents include the sales price and the corresponding financial and tax information. Each transaction level corresponds to a pricing strategy. The pricing strategy includes at least one calculation factor. The calculation factor is various basic data used to participate in the price calculation. The second calculation submodule is used to calculate the sales price of each commodity denominated in the standard currency for each transaction level if the transaction type of the transaction level is a non-fiduciary currency transaction, using a preset standard currency as the transaction currency, and calculating the sales price of each commodity denominated in the standard currency according to the pricing strategy corresponding to the transaction level in the target transaction chain, and generating financial and tax documents corresponding to the transaction of the transaction level at the downstream node of the transaction level.

[0135] In some embodiments, the document generation device may further include: The fourth acquisition module is used to acquire the document generation instruction initiated by the business system, and query whether there is a corresponding target financial and tax document record in the preset database based on the business document identifier and transaction link identifier in the document generation instruction. The document generation instruction includes the business document identifier and the transaction link identifier. The termination module is used to terminate the tax document generation process if the target tax document record exists and the execution status of the target tax document record is successful.

[0136] In some embodiments, the document generation device may further include: The storage module is used to store the financial and tax documents corresponding to the target business document into the database, and to create or update the corresponding record status as successful.

[0137] In some embodiments, the document generation device may further include: The second verification module is used to verify the number and order of nodes in the target transaction link; wherein there is exactly one shipping node and exactly one receiving node, and the shipping node is in the order of the receiving node; if there is an exit node, the exit node is in the order of the import node; if the exit node and the shipping node coincide, the exit node and the shipping node share the same node identifier; if the import node and the receiving node coincide, the import node and the receiving node share the same node identifier.

[0138] The specific implementation of this document generation device is basically the same as the specific implementation of the document generation method described above, and will not be repeated here.

[0139] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described document generation method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0140] Please see Figure 4 , Figure 4 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 801 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 802 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 802 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 802 and is called and executed by the processor 801 using the document generation method of the embodiments of this application. The 803 input / output interface is used to implement information input and output. The communication interface 804 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 805 transmits information between various components of the device (e.g., processor 801, memory 802, input / output interface 803, and communication interface 804); The processor 801, memory 802, input / output interface 803, and communication interface 804 are connected to each other within the device via bus 805.

[0141] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described document generation method.

[0142] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0143] The document generation method, device, electronic equipment, and storage medium provided in this application obtain a document creation request initiated by the business system, which includes the business type, originating node, and target node. Based on this dimensional information, it automatically filters out matching target transaction links from a preset transaction link library and returns the main information to the business system for business processing. Subsequently, it receives the target business document containing product identifiers from the business system, obtains the price based on the product identifiers, and automatically generates the corresponding financial and tax documents in conjunction with the pricing strategy corresponding to the target transaction link. This application realizes automatic linkage between the business system and the financial and tax system, ensuring consistency throughout the entire process of transaction path, pricing calculation, and document generation, effectively improving financial processing efficiency and tax compliance.

[0144] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0145] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0146] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0147] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0148] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0149] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

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

[0151] The units described above 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.

[0152] Furthermore, the functional units in the various embodiments of 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0153] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part 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 multiple 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 of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0154] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for generating documents, characterized in that, The method includes: Obtain a document creation request initiated by the business system, wherein the document creation request includes the business type of the transaction, the originating node, and the target node; Based on the business type, the originating node, and the target node, the transaction links corresponding to multiple transactions are filtered to obtain the target transaction links. Each transaction link includes transaction subject information and a transaction link identifier. The transaction link identifier is used to identify a unique transaction link formed by connecting at least two nodes in sequence. The at least two nodes include the originating node and the target node of the transaction. The system receives a transaction link acquisition request sent by the business system. The transaction link acquisition request is used to acquire the transaction subject information and the transaction link identifier of the target transaction link. Obtain the target business document created by the business system based on the transaction entity information and the transaction link identifier of the target transaction link. The target business document includes the identifier of the traded goods and the transaction link corresponding to the target business document. The price of the goods in the target business document is calculated based on the product identifier in the target business document and the pricing strategy corresponding to the target transaction link, and a financial and tax document corresponding to the target business document is generated.

2. The method according to claim 1, characterized in that, The step of filtering the transaction links corresponding to multiple transactions based on the business type, the originating node, and the target node to obtain the target transaction link includes: Based on the business type, the originating node, and the target node, the transaction links corresponding to each of the multiple transactions are filtered to obtain at least one matching transaction link that matches the business type, the originating node, and the target node. If there are multiple matching transaction links, then obtain the priority value corresponding to the transaction link identifier of each of the multiple matching transaction links; The transaction link with the highest priority value is selected as the target transaction link.

3. The method according to claim 2, characterized in that, The business types include supplier direct mail business, physical warehouse business and store business. The supplier direct mail business refers to the business in which the supplier, as the originating node, directly sends the goods to the warehouse or store. The physical warehouse business refers to the business in which the physical warehouse, as the originating node or the target node, is used. The store business refers to the business in which the store, as the target node, is used. The step of filtering the transaction links corresponding to multiple transactions based on the business type, the originating node, and the target node to obtain the target transaction link includes: If no matching transaction link is found that matches the business type, the originating node, and the target node, then it is determined whether the business type in the document creation request belongs to the supplier direct mail business. If the business type in the document creation request belongs to the supplier direct mail business, then the originating node is configured to all suppliers, and the corresponding first default transaction link is matched based on the originating node; If the business type in the document creation request does not belong to the supplier direct mail business, then obtain the transaction entity information, delivery node and receiving node corresponding to the physical warehouse business or the store business. Based on the transaction entity information, the shipping node, and the receiving node, a corresponding second default transaction link is matched.

4. The method according to claim 1, characterized in that, After obtaining the target business document created by the business system based on the transaction entity information and the transaction link identifier of the target transaction link, and before calculating the price of the goods in the target business document according to the product identifier in the target business document and the pricing strategy corresponding to the target transaction link, and before generating the financial and tax documents corresponding to the target business document, the method further includes: If a node with a pre-configured control type is detected in the target transaction link, the node type of each node in the target transaction link is obtained. The node type includes the shipping node type, receiving node type, import node type and export node type. The control type includes the inbound control type and the outbound control type. The nodes are verified according to their arrangement order in the target transaction link. If there is a node configured as outbound in-transit control type after the node of the shipping node type or the export node type, then the first node configured as outbound in-transit control type in the target transaction link is determined as the in-transit control subject. If the target transaction link includes nodes of the export node type, and the receiving node type has enabled the inbound control type, and no other inbound control node type is set between the export node type node and the receiving node type node, then the control type assigned to each node in the target transaction link is saved.

5. The method according to claim 1, characterized in that, The step of calculating the price of the goods in the target business document based on the product identifier in the target business document and the pricing strategy corresponding to the target transaction link, and generating the financial and tax documents corresponding to the target business document, includes: Obtain the transaction layers contained in the target transaction chain, as well as the upstream and downstream nodes of each transaction layer; For each transaction level, if the transaction type of the transaction level is a local currency transaction, then the currency of the upstream node is used as the transaction currency. The sales price of each commodity is calculated in the currency of the upstream node according to the pricing strategy corresponding to the transaction level in the target transaction chain. Then, a financial and tax document corresponding to the transaction of the transaction level is generated at the downstream node of the transaction level. The financial and tax document contains the sales price and the corresponding financial and tax information. Each transaction level corresponds to a pricing strategy. The pricing strategy includes at least one calculation factor. The calculation factor is various basic data used to participate in the price calculation. For each transaction level, if the transaction type of the transaction level is a non-fiduciary currency transaction, then a preset standard currency is used as the transaction currency. The sales price of each commodity denominated in the standard currency is calculated according to the pricing strategy corresponding to the transaction level in the target transaction chain, and financial and tax documents corresponding to the transaction of the transaction level are generated at the downstream node of the transaction level.

6. The method according to claim 1, characterized in that, Before calculating the price of the goods in the target business document based on the product identifier in the target business document and the pricing strategy corresponding to the target transaction link, and generating the financial and tax documents corresponding to the target business document, the method further includes: Obtain a document generation instruction initiated by the business system, and query whether there is a corresponding target financial and tax document record in the preset database based on the business document identifier and transaction link identifier in the document generation instruction. The document generation instruction includes a business document identifier and a transaction link identifier. If the target financial and tax document record exists and the execution status of the target financial and tax document record is successful, then the financial and tax document generation process is terminated.

7. The method according to claim 6, characterized in that, After calculating the price of the goods in the target business document based on the product identifier in the target business document and the pricing strategy corresponding to the target transaction link, and generating the financial and tax documents corresponding to the target business document, the method further includes: Store the financial and tax documents corresponding to the target business document in the database, and create or update the corresponding record status to successful.

8. The method according to claim 1, characterized in that, After filtering the transaction links corresponding to multiple transactions according to the business type, the originating node, and the target node to obtain the target transaction link, before sending the transaction subject information and the transaction link identifier of the target transaction link to the business system, the method further includes: Verify the number and order of nodes in the target transaction chain; There is one and only one shipping node and one receiving node, and the shipping node is located before the receiving node in sequence. If an exit node exists, the exit node is in the order of the import node; If the export node coincides with the shipping node, then the export node and the shipping node share the same node identifier; If the import node and the receiving node coincide, then the import node and the receiving node share the same node identifier.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the document generation method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the document generation method according to any one of claims 1 to 7.

Images