A fine cost accounting method for cross-border multi-agent e-commerce
By using a document-driven event mechanism and a multi-currency cost splitting algorithm, the system solves the data inconsistency and performance bottleneck problems of the financial accounting system of cross-border e-commerce groups in the context of multiple currencies, multiple cost structures, and complex internal transactions. It enables real-time and accurate cost calculation and full lifecycle tracking in multiple currencies and with multiple calibers, supporting efficient financial management.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- FUJIAN YANGTENG INNOVATION INFORMATION TECHNOLOGY CO LTD
- Filing Date
- 2026-05-25
- Publication Date
- 2026-06-19
AI Technical Summary
When dealing with multiple currencies, multiple cost structures, and complex internal transactions, the financial accounting system of cross-border e-commerce groups suffers from problems such as a single cost definition, a crude cost structure, fragmented processing of related transactions, and data backtracking and performance bottlenecks, resulting in inconsistent data, low efficiency, and susceptibility to errors.
Employing a document-driven event mechanism and a multi-currency cost splitting algorithm, the system receives and parses original documents, identifies inter-company transactions, generates derivative documents, and calculates and updates inventory costs in real time, enabling refined accounting across multiple currencies and cost items.
It enables real-time and accurate calculation of costs in multiple currencies and with multiple calibers, supports consistency of financial data inside and outside the group, tracks the entire cost lifecycle in a refined manner, automates inter-company transactions, and builds a high-performance real-time rolling cost calculation system.
Smart Images

Figure CN122243560A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of data processing and financial cost accounting technology, and in particular to a refined cost accounting method for cross-border multi-entity e-commerce. Background Technology
[0002] In the cross-border e-commerce sector, group companies selling goods on platforms typically have complex business models, often involving: 1. Multiple Entities and Multiple Currencies: The group includes multiple subsidiaries registered in different countries / regions, each with its own base currency (such as CNY, USD, EUR). Furthermore, procurement transactions may be settled in US dollars (USD), while sales may be directly collected in euros (EUR), resulting in a separation of the "procurement currency," "transaction currency," and "base currency."
[0003] 2. Multiple cost components: Commodity costs include not only the purchase price (item cost), but also the first-leg ocean freight, customs duties, insurance premiums, port handling fees, etc. These costs account for a huge proportion and fluctuate frequently.
[0004] 3. Complex intra-company transactions: Before reaching the end consumer, goods may circulate among multiple subsidiaries within the group. Such inter-company transactions (related party transactions) are usually accompanied by internal markups, which also need to be included in the final cost of sales.
[0005] In existing technologies, traditional Enterprise Resource Planning (ERP) systems or financial accounting systems have the following drawbacks when handling such complex business processes: 1. Limited cost accounting: Costs are typically calculated in only one currency (such as the functional currency), which cannot simultaneously meet the dual requirements of management reports (costs are viewed in the purchasing currency) and financial reports (costs are calculated in the functional currency). This leads to data inconsistencies, requiring manual secondary processing, which is inefficient and prone to errors.
[0006] 2. Incomplete cost structure: Inventory costs are often recorded as a total amount, without being broken down into detailed items such as item cost, shipping cost, and tariffs. This lack of granular data makes it difficult to analyze cost changes or file tax returns.
[0007] 3. Fragmented processing of related-party transactions: For internal transactions such as transfers and sales between companies, traditional systems either cannot automatically process internal markups, or process the markup as a separate account on financial vouchers, failing to deferred and track it as part of inventory costs. This results in incomplete cost accounting when downstream sales are shipped out, and cannot truly reflect the full-chain cost of goods.
[0008] 4. Data backtracking and performance bottlenecks: When cost calculation is separated from business documents (such as outbound and inbound orders), if upstream cost data (such as first-leg fees) lags behind, complex backtracking adjustments need to be made to the costs that have already been shipped. This is not only logically complex, but also easily causes system performance bottlenecks when the data volume is large (such as tens of thousands of orders per day), affecting real-time business. Summary of the Invention
[0009] In view of this, the purpose of this invention is to propose a refined cost accounting method for cross-border multi-entity e-commerce. By using a document-driven event mechanism and a multi-currency cost splitting algorithm, the complex cost accounting is decomposed into the processing of each document, thereby achieving real-time and accurate cost calculation.
[0010] To achieve the above-mentioned technical objectives, the technical solution adopted by this invention is as follows: This invention provides a refined cost accounting method for cross-border multi-entity e-commerce, specifically including the following steps: Step 1: Receive the original documents, parse them, and extract the key information fields; Step 2: Determine whether the current original document belongs to an inter-company transaction based on the key information fields. If yes, proceed to Step 3; otherwise, proceed to Step 5. Step 3: Locate the preset transaction link and determine whether the current original document matches the transaction link segment rule based on the key information fields. Step 4: When the transaction link segment rule is hit, a derivative document is generated. The derivative document includes at least an internal sales order, a sales delivery order, an internal purchase order, and a purchase receipt in transit order. Step 5: Perform inbound cost calculation for internal purchase orders and inbound purchase receipts: break down the inbound cost into multiple cost items, calculate the amount of each cost item in the transaction currency, local currency, and purchase currency in parallel, and use the batch inbound deduction algorithm to determine the inbound cost for this time. Step 6: Calculate outbound costs for internal sales orders and sales delivery orders: Lock out outbound costs based on the weighted average unit price of the current inventory, and simultaneously transfer the amount of each cost item in the transaction currency, base currency, and purchase currency. Step 7: Update the cost balance of the inventory in real time based on the calculation results of inbound and outbound transactions; Step 8: Generate and save the corresponding transaction records for the detailed status before and after each inventory change.
[0011] Furthermore, step 1 specifically includes: Step 11: When a real inbound or outbound transaction occurs, the ERP system sends the original document to the cost center system. The original document is in JSON or XML format. Step 12: The cost center system receives original documents via API interface by listening for messages; Step 13: The cost center system parses the original documents, extracts key information fields from the original documents, and stores them in the original document table of the cost center database; The key information fields include at least the document type, business type, warehouse identifier, owner identifier, SKU code, quantity, business time, and associated document number; when the document type is a sales outbound order, the key information fields also include the sales account identifier. The document types include purchase receipt, transfer order, and sales order, which are used to identify whether the original document is a receipt or an order. The business types include purchase receipt, transfer receipt, and sales receipt, which are used to identify specific business scenarios to match cost calculation rules; The warehouse identifier is used to obtain the warehouse type and the warehouse where the goods are actually stored by associating with the warehouse master data table, and then associate it with the cargo owner entity to which the warehouse belongs; The cargo owner identifier is used to identify the entity to which the cargo is owned. It is directly provided by the ERP system based on the cargo owner entity and is used to determine whether a change of cargo owner entity has occurred. The SKU code is used to uniquely identify products and serves as a basic dimension for cost accounting. The quantity refers to the quantity of goods entering and leaving the warehouse this time, which is used for cost calculation and inventory quantity updates; The business time refers to the actual time when the business occurs, used for querying exchange rates; The associated document number is used to trace the source of the business and associate it with in-transit orders; The sales account identifier serves as a query index for the mapping table between stores and entities, allowing users to query the accounting entity corresponding to the sales account.
[0012] Furthermore, step 2 specifically includes: Step 21: Extract the document type and business type from the original document table. Determine whether the current original document belongs to an inter-company transaction based on the document type and business type. If the document type is a transfer order and the business type is a transfer order, or if the document type is a sales order and the business type is a sales order, proceed to step 22. If the document type is other types, determine that the original document is a transfer transaction within the same entity, which belongs to a non-inter-company transaction, and proceed to step 5. Step 22: Identify inter-company transactions using different identification rules based on document type, as detailed below: For transfer and outbound orders, a transfer and outbound identification rule is adopted, which specifically includes the following steps: (1) Extract the warehouse identifier from the original document table, and query the warehouse master data table through the warehouse identifier to obtain the warehouse type and the cargo owner to which the warehouse belongs; the warehouse type includes physical warehouses and virtual warehouses, and the virtual warehouses include virtual transit warehouses and virtual forward warehouses; (2) Extract the associated document number from the original document table as the transfer outbound order number, and use the transfer outbound order number to call the ERP interface to obtain the transfer outbound order information or query the local cached transfer outbound order information; determine whether the transfer outbound order has a transaction link identifier based on the transfer outbound order information. (3) If the warehouse type is not a virtual warehouse and there is a transaction link identifier, it is determined to be an inter-company transaction; if the warehouse type is a virtual warehouse or there is no transaction link identifier, the original document is determined to be a transfer transaction within the same entity, which is a non-inter-company transaction, and proceed to step 5. For sales delivery orders, a sales delivery identification rule is used, which specifically includes the following steps: (1) Extract the owner's main identifier from the original document table; (2) Extract the sales account identifier from the original document table, query the mapping relationship table between the store and the entity through the sales account identifier, and obtain the accounting entity identifier corresponding to the sales account identifier; (3) Determine whether the owner's identifier and the accounting entity identifier are consistent. If yes, the original document is determined to be a normal sales transaction and belongs to a non-inter-company transaction. Proceed to step 5. If no, the original document is determined to be an inter-company transaction. Proceed to step 3.
[0013] Furthermore, step 3 specifically includes: Step 31: Pre-configure the transaction chain. Each transaction chain is stored in the transaction master data table in JSON format. The core fields of each transaction chain include at least: transaction chain identifier, ordered node array, and node segment rule array. Each node in the ordered node array contains a node sequence number and a node subject ID. Each node segment rule in the node segment rule array contains a seller subject ID, a buyer subject ID, a markup rate, a transaction currency, a markup factor, and an identifier indicating whether a tax refund difference is involved. Step 32: After determining that the original document is an inter-company transaction, locate the preset transaction link based on the transaction link identifier; the specific method is as follows: (1) Query the warehouse master data table based on the warehouse identifier to obtain the corresponding cargo owner entity as the current entity; (2) Obtain the counterparty entity according to the document type; for transfer outbound order, obtain the entity to which the destination warehouse belongs from the transfer outbound order information as the counterparty entity; for sales outbound order, obtain the accounting entity to which the corresponding accounting entity identifier belongs according to the sales account identifier as the counterparty entity. (3) Traverse all configured transaction links and search for a transaction link whose node order includes adjacent segments from the current entity to the counterparty entity, i.e., the seller entity to which the seller entity ID belongs is the current entity and the buyer entity to which the buyer entity ID belongs is the counterparty entity; if it exists, the transaction link segment rule is hit, the markup rate and transaction currency in the transaction link segment rule are recorded, and step 4 is entered; if it does not exist, the original document is determined to be a transfer transaction within the same entity, which belongs to a non-company transaction, and step 5 is entered.
[0014] Furthermore, step 4 specifically includes: When a transaction link segment rule is hit, the derivative document generation engine is triggered. This derivative document generation engine performs the following operations within a transaction in the same order database: creating internal sales orders and sales delivery orders, creating internal purchase orders and purchase receipts in transit orders, storing related relationships, and rolling back transactions if operations fail. (1) The method for creating internal sales orders and sales delivery slips is as follows: Generate a new internal sales order. The order number of the internal sales order is formed by concatenating the prefix GISSO, the current date, and the serial number. The seller in the internal sales order is the current entity, the buyer is the counterparty, and the transaction currency is taken from the transaction currency of the matching transaction link segment rule in the transaction link. Calculate the transaction amount in the internal sales order. Generate a corresponding sales delivery order, which is associated with the internal sales order. The delivery quantity is consistent with the quantity in the original document, and the delivery cost is determined using the algorithm for calculating delivery costs. (2) The method for creating internal purchase orders and purchase receipts in transit is as follows: Generate a new internal purchase order. The order number of the internal purchase order is composed of the prefix GISPO, the current date, and the serial number. The seller of the internal purchase order is the current entity, and the buyer is the counterparty. The transaction currency of the internal purchase order is the same as that of the internal sales order, and the transaction amount of the internal purchase order is the same as that of the internal sales order. Generate a purchase receipt in transit order. The total quantity in transit in the purchase receipt in transit order is equal to the quantity in the original document, and the total cost in transit is equal to the transaction currency amount of the internal sales order. Then, break down and store each cost item. (3) The storage association method is as follows: all derived documents record the upstream document number field of the derived source, which points to the document number of the original document; (4) The method for rolling back the transaction in case of failure is as follows: the five operations of creating an internal sales order, creating a sales delivery order, creating an internal purchase order, creating a purchase receipt in transit order, and storing the relationship are placed in the same transaction of the order database; when any of these five operations fails, all operations executed in the transaction are automatically rolled back, so that the order database is restored to the state before the start of the transaction.
[0015] Furthermore, the calculation of warehousing costs in step 5 specifically includes: Step 51: For internal purchase orders, the warehousing cost is broken down into multiple cost items. Each cost item is stored independently in the cost center database and simultaneously records three currency fields: transaction currency amount, local currency amount, and purchase currency amount. The cost items include: item cost, first-mileage fee, customs duty, tax refund difference, and markups for each segment. The markups for each segment are numbered sequentially according to the transaction segment rules in the transaction chain, and each markup is stored and calculated as an independent cost item. Step 52: Calculate the amount of each cost item in parallel under the transaction currency, base currency, and procurement currency, as follows: (1) Maintain an exchange rate table in advance, which includes the original currency, target currency, exchange rate, exchange rate type and effective date, wherein the exchange rate type includes accounting exchange rate and customs exchange rate; (2) Calculate the transaction amount of the internal purchase order in currency, using the formula: Transaction amount in currency = Original document cost × (1 + markup rate) × Current exchange rate; The original document cost is calculated using the markup factor; (3) Query the current exchange rate corresponding to the effective date of the current exchange rate type according to the business time and the main time zone, and calculate the base currency amount. The formula is: base currency amount = transaction currency amount × current exchange rate; (4) Obtain the purchase currency amount from the internal purchase order; (5) Write the amounts in three currencies for the same cost item into three independent fields in the same row of the cost center database in parallel; Step 53: Determine the cost of this inbound shipment using a batch-by-batch inbound deduction algorithm; details are as follows: (1) For a purchase receipt in transit, the total quantity in transit Q, the total cost in transit C, the quantity already received q_in, and the cost already received c_in are recorded; (2) When a new purchase receipt is received and the new receipt quantity is q_new, if q_in+q_new<Q, then the receipt cost = (C / Q) × q_new; if q_in+q_new=Q, then the receipt cost = C-c_in.
[0016] Furthermore, the calculation of outbound costs in step 6 specifically includes: Step 61: This is achieved by maintaining an inventory cost table, which records the weighted average unit price of each cost item in the current inventory according to three dimensions: owner identifier, warehouse identifier, and SKU code. The weighted average unit price is calculated as follows: Weighted average unit price = Total amount of current inventory for the cost item / Total quantity of current inventory. The cost items include the cost of goods, initial shipping costs, customs duties, tax refund differences, and surcharges for each segment. The formula for calculating the specific unit price of each cost item is as follows: (1) Unit cost of goods = Total cost of goods in the inventory cost table / Total quantity; (2) Unit price of first-leg cost = total amount of first-leg cost in the inventory cost table / total quantity; (3) Tariff unit price = Total tariff amount in the inventory cost table / Total quantity; (4) Tax refund difference unit price = total amount of tax refund difference in the inventory cost table / total quantity; (5) The unit price of each segment = the total amount of the segment's price increase / the total quantity; Step 62: Upon confirmation of outbound shipment, read the weighted average unit price of the SKU in the inventory cost table and calculate the total outbound cost and the outbound amount of each cost item using the following formula; details are as follows: Total outbound cost for each SKU = outbound quantity × weighted average unit price of the SKU; Cost of outbound items for each SKU = Quantity outbound × Unit cost of items; Outbound first-leg cost for each SKU = outbound quantity × first-leg cost unit price; Outbound tariff for each SKU = Outbound quantity × Tariff unit price; Tax refund difference for each SKU = outbound quantity × tax refund difference unit price; The markup for each SKU at each stage of outbound shipment = outbound quantity × markup unit price for each stage; Step 63: Calculate the transaction currency, local currency, and purchase currency for each cost item's outbound amount in parallel; details are as follows: Local currency amount = quantity issued × local currency weighted average unit price, local currency weighted average unit price = total local currency amount / total quantity in the inventory cost table; Purchase amount in currency = quantity issued × weighted average unit price in currency; weighted average unit price in currency = total purchase amount in currency / total quantity in the inventory cost table. The transaction amount is calculated in reverse from the base currency amount using the transaction exchange rate. The specific formula is: Transaction amount = Base currency amount / Transaction exchange rate.
[0017] Furthermore, step 7 specifically includes: after each inbound or outbound transaction is completed, immediately update the inventory cost table; wherein, the update process after inbound and the update process after outbound are executed separately, and the update method for each cost item is the same and completed independently; (1) The update process after warehousing is as follows: New total quantity = original total quantity + warehousing quantity, new total cost item amount = original total cost item amount + the amount of this cost item in this warehousing, new cost item unit price = new total cost item amount / new total quantity; specifically as follows: The total cost of new items = the total cost of original items + the cost of items put into storage; the unit cost of new items = the total cost of new items / the total quantity of new items. New first-leg cost total amount = original first-leg cost total amount + warehousing first-leg cost amount, new first-leg cost unit price = new first-leg cost total amount / new total quantity; New tariff total amount = original tariff total amount + tariff amount incurred into the warehouse; new tariff unit price = new tariff total amount / new total quantity. New tax refund difference total amount = original tax refund difference total amount + warehousing tax refund difference total amount, new tax refund difference unit price = new tax refund difference total amount / new total quantity; The total price increase for each new segment = the total price increase for each original segment + the total price increase for each segment upon entry into the warehouse; the unit price of the price increase for each new segment = the total price increase for each new segment / the total quantity of the new segment. (2) The update process after the goods are shipped out is as follows: New total quantity = Original total quantity - Quantity shipped out, New total cost item amount = Original total cost item amount - Amount of this cost item shipped out, New unit price of cost item = New total cost item amount / New total quantity; Specifically as follows: Total cost of new items = Total cost of original items - Cost of items issued from the warehouse; Unit cost of new items = Total cost of new items / Total quantity of new items. New total first-leg cost = Original total first-leg cost - Outbound first-leg cost; New first-leg cost unit price = New total first-leg cost / New total quantity. New total tariff amount = original total tariff amount - outbound tariff amount; new tariff unit price = new total tariff amount / new total quantity. New total tax refund difference = original total tax refund difference - outbound tax refund difference; new tax refund difference unit price = new total tax refund difference / new total quantity. The total amount of the new price increase for each segment = the total amount of the original price increase for each segment - the total amount of the price increase for each segment upon delivery; the unit price of the new price increase for each segment = the total amount of the new price increase for each segment / the total quantity. When the total quantity becomes zero after shipment, the unit price will be retained as the last unit price before shipment.
[0018] Furthermore, step 8 specifically includes: Generate a transaction record for each inventory change and store the transaction record in the inventory change transaction record table; each transaction record contains the following fields: quantity before change, quantity after change, total amount of each cost item before change, total amount of each cost item after change, unit price of each cost item before change, unit price of each cost item after change, associated document number, SKU code, warehouse identifier, and business time. The total amount of each cost item before the change includes the total cost of goods before the change, the total amount of first-leg expenses before the change, the total amount of customs duties before the change, the total amount of tax refund difference before the change, and the total amount of price increase for each segment before the change. The total amount of each cost item after the change includes the total amount of the changed item cost, the total amount of the changed first-leg expenses, the total amount of the changed customs duties, the total amount of the changed tax refund difference, and the total amount of the changed price increase for each segment. The unit prices of each cost item before the change include the unit price of the item cost before the change, the unit price of the first leg fee before the change, the unit price of the customs duty before the change, the unit price of the tax refund difference before the change, and the unit price of each segment's surcharge before the change. The revised unit prices for each cost item include the revised unit price for the cost of the goods, the revised unit price for the initial leg of the journey, the revised unit price for customs duties, the revised unit price for the tax refund difference, and the revised unit price for each segment's additional charges.
[0019] Furthermore, after step 8, the method further includes: sending the generated transaction records to the financial voucher system, wherein the financial voucher system performs at least one of the following based on the transaction records: cost variance analysis, audit traceability analysis, voucher generation, financial statement management, and financial reconciliation management; The cost variance analysis specifically involves: finance personnel querying the inventory cost composition at any point in time based on the transaction records, comparing the cost differences of different batches of goods received, and identifying the reasons for abnormal cost fluctuations. The audit traceability analysis specifically involves: when a cost error occurs, reverse calculations are performed using transaction records to identify the specific documents and operations in which the error occurred, which are then used for data repair. Financial statement management specifically involves extracting data from transaction records by time interval and summarizing it by purchase currency to generate financial statements. Financial reconciliation management specifically involves generating vouchers based on transaction records.
[0020] By adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art: 1. Enabled parallel cost accounting for multiple currencies and different cost standards: By simultaneously recording the amounts in the transaction currency, functional currency, and procurement currency for each cost item during the warehousing process, the discrepancy between the accounting standards of management reports (based on procurement currency) and financial reports (based on functional currency) is perfectly resolved. Data from the same source and generated in real time ensures the consistency and accuracy of financial data both within and outside the group, avoiding the manual conversion and data verification work required by traditional methods.
[0021] 2. Achieved refined breakdown and tracking of costs throughout the entire lifecycle: Costs are broken down from a single "item cost" into multiple sub-items such as "item cost," "shipping cost," "customs duties," "tax refund difference," and "markup." Each cost sub-item is tracked throughout the entire process from "purchase receipt -> inventory balance -> sales shipment," allowing businesses to precisely analyze cost composition and pinpoint the root causes of cost fluctuations (e.g., whether increased purchase prices or soaring shipping costs are causing a rise in total costs), providing unprecedented data support for refined operations and cost control.
[0022] 3. Enabled automated and seamless processing of inter-company transaction costs: Through pre-defined transaction links and rules, complex transactions such as inter-company transfers and sales can be automatically identified and processed. The generated internal markup is no longer an isolated financial item, but is seamlessly integrated into the target company's inventory cost as a cost item called "markup". When the goods are finally sold and shipped, their cost fully includes the markups from all internal circulation links, truly reflecting the value of the goods across the entire chain, and greatly simplifying the preparation of consolidated financial statements for the group.
[0023] 4. A high-performance, real-time rolling cost calculation system has been built: Employing a document-driven event mechanism, cost calculation is linked to business transactions in real time. Every inbound and outbound transaction is an instant update of inventory costs, ensuring the timeliness of cost data. Through "in-transit orders" and a "reverse deduction algorithm," the system elegantly solves the cost allocation problem for goods arriving in batches, avoiding large-scale data backtracking later. Even in high-concurrency, massive-data scenarios (such as tens of thousands of orders per day), the system maintains stable, efficient operation and data accuracy. Attached Figure Description
[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0025] Figure 1This is an execution flowchart of a refined cost accounting method for cross-border multi-entity e-commerce provided by an embodiment of the present invention. Detailed Implementation
[0026] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be particularly noted that the following embodiments are for illustrative purposes only and do not limit the scope of the invention. Similarly, the following embodiments are only some, not all, embodiments of the present invention, and all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0027] Please see Figure 1 This invention discloses a refined cost accounting method for cross-border multi-entity e-commerce. The method is applied between an ERP system, a cost center system, and a financial voucher system. By receiving original documents from the ERP system, and based on preset business rules, transaction links, and exchange rate information, it dynamically calculates and generates derivative documents containing multiple currencies and cost details, and updates the cost balance of inventory in real time. Its core lies in using a document-driven event mechanism and a multi-currency cost splitting algorithm to decompose complex cost accounting into processing each document, achieving real-time and accurate cost calculation. The method specifically includes the following steps: Step 1: Receive the original documents, parse them, and extract the key information fields; In this embodiment, step 1 specifically includes: Step 11: When a real inbound / outbound transaction occurs (such as purchase inbound, sales outbound, or transfer outbound), the ERP system (as a business event trigger used for managing inventory and inbound / outbound transactions) sends the original document to the cost center system. The original document is in JSON or XML format. Step 12: The cost center system receives original documents via API interface by listening for messages; Step 13: The cost center system parses the original documents, extracts key information fields from the original documents (each field has a clear storage location and purpose), and stores them in the original document table of the cost center database; The key information fields include at least the document type, business type, warehouse identifier, owner identifier, SKU code, quantity, business time, and associated document number; when the document type is a sales outbound order, the key information fields also include the sales account identifier. The document types include purchase receipt, transfer order, and sales order, which are used to identify whether the original document is a receipt or an order. The business types include purchase receipt, transfer receipt, and sales receipt, which are used to identify specific business scenarios to match cost calculation rules; The warehouse identifier is used to obtain the warehouse type and the warehouse where the goods are actually stored by associating with the warehouse master data table, and then associate it with the cargo owner entity to which the warehouse belongs; The cargo owner identifier is used to identify the entity to which the cargo is owned. It is directly provided by the ERP system based on the cargo owner entity and is used to determine whether a change of cargo owner entity has occurred. The SKU (Stock Keeping Unit) code is used to uniquely identify products and serves as a basic dimension for cost accounting; The quantity refers to the quantity of goods entering and leaving the warehouse this time, which is used for cost calculation and inventory quantity updates; The business time refers to the actual time when the business occurs (including time zone information), which is the point in time used to query exchange rates; The associated document number is used to trace the source of business and associate in-transit documents, such as purchase order number, transfer order number, sales order number, etc. The sales account identifier serves as a query index for the mapping table between stores and entities, allowing users to query the accounting entity corresponding to the sales account.
[0028] Step 2: Determine whether the current original document belongs to an inter-company transaction based on the key information fields. If yes, proceed to Step 3; otherwise, proceed to Step 5. In this embodiment, step 2 specifically includes: Step 21: Extract the document type and business type from the original document table. Determine whether the current original document belongs to an inter-company transaction based on the document type and business type. If the document type is a transfer order and the business type is a transfer order, or if the document type is a sales order and the business type is a sales order, proceed to step 22. If the document type is other types, determine that the original document is a transfer transaction within the same entity, which belongs to a non-inter-company transaction, and proceed to step 5. Step 22: Identify inter-company transactions using different identification rules based on document type, as detailed below: For transfer and outbound orders, a transfer and outbound identification rule is adopted, which specifically includes the following steps: (1) Extract the warehouse identifier from the original document table, and query the warehouse master data table through the warehouse identifier to obtain the warehouse type and the cargo owner to which the warehouse belongs; the warehouse type includes physical warehouses and virtual warehouses, and the virtual warehouses include virtual transit warehouses and virtual forward warehouses; (2) Extract the associated document number from the original document table as the transfer outbound order number, and use the transfer outbound order number to call the ERP interface to obtain the transfer outbound order information or query the local cached transfer outbound order information; determine whether the transfer outbound order has a transaction link identifier based on the transfer outbound order information. (3) If the warehouse type is not a virtual warehouse and there is a transaction link identifier, it is determined to be an inter-company transaction; if the warehouse type is a virtual warehouse or there is no transaction link identifier, the original document is determined to be a transfer transaction within the same entity, which is a non-inter-company transaction, and proceed to step 5. For sales delivery orders, a sales delivery identification rule is used, which specifically includes the following steps: (1) Extract the owner's main identifier from the original document table; (2) Extract the sales account identifier from the original document table, query the mapping relationship table between the store and the entity through the sales account identifier, and obtain the accounting entity identifier corresponding to the sales account identifier; (3) Determine whether the owner's identifier and the accounting entity identifier are consistent. If yes, the original document is determined to be a normal sales transaction and belongs to a non-inter-company transaction. Proceed to step 5. If no, the original document is determined to be an inter-company transaction. Proceed to step 3.
[0029] Step 3: Locate the preset transaction link and determine whether the current original document matches the transaction link segment rule based on the key information fields. In this embodiment, step 3 specifically includes: Step 31: Finance personnel pre-configure transaction links through the transaction link configuration module. Each transaction link is stored in the transaction master data table in JSON format. The core fields of each transaction link include at least: transaction link identifier, ordered node array, and node segment rule array. Each node in the ordered node array contains a node sequence number and a node subject ID. Each node segment rule in the node segment rule array contains a seller subject ID, a buyer subject ID, a markup rate, a transaction currency, a markup factor, and an identifier indicating whether a tax refund difference is involved. Step 32: After determining that the original document is an inter-company transaction, locate the preset transaction link based on the transaction link identifier; the specific method is as follows: (1) Query the warehouse master data table based on the warehouse identifier to obtain the corresponding cargo owner entity as the current entity; (2) Obtain the counterparty entity according to the document type; for transfer outbound order, obtain the entity to which the destination warehouse belongs from the transfer outbound order information as the counterparty entity; for sales outbound order, obtain the accounting entity to which the corresponding accounting entity identifier belongs according to the sales account identifier as the counterparty entity. (3) Traverse all configured transaction links and search for a transaction link whose node order includes adjacent segments from the current entity to the counterparty entity, i.e., the seller entity to which the seller entity ID belongs is the current entity and the buyer entity to which the buyer entity ID belongs is the counterparty entity; if it exists, the transaction link segment rule is hit, the markup rate and transaction currency in the transaction link segment rule are recorded, and step 4 is entered; if it does not exist, the original document is determined to be a transfer transaction within the same entity, which belongs to a non-company transaction, and step 5 is entered.
[0030] Step 4: When the transaction link segment rule is hit, a derivative document is generated. The derivative document includes at least an internal sales order, a sales delivery order, an internal purchase order, and a purchase receipt in transit order. In this embodiment, step 4 specifically includes: When a transaction link segment rule is hit, the derivative document generation engine is triggered. This derivative document generation engine performs the following operations within a transaction in the same order database: creating internal sales orders and sales delivery orders, creating internal purchase orders and purchase receipts in transit orders, storing related relationships, and rolling back transactions if operations fail. (1) The method for creating internal sales orders and sales delivery slips is as follows: Generate a new internal sales order. The order number of the internal sales order is formed by concatenating the prefix GISSO, the current date, and the serial number. The seller in the internal sales order is the current entity, the buyer is the counterparty, and the transaction currency is taken from the transaction currency of the matching transaction link segment rule in the transaction link. Calculate the transaction amount in the internal sales order. Generate a corresponding sales delivery order, which is associated with the internal sales order. The delivery quantity is consistent with the quantity in the original document, and the delivery cost is determined using the algorithm for calculating delivery costs. (2) The method for creating internal purchase orders and purchase receipts in transit is as follows: Generate a new internal purchase order. The order number of the internal purchase order is composed of the prefix GISPO, the current date, and the serial number. The seller of the internal purchase order is the current entity, and the buyer is the counterparty. The transaction currency of the internal purchase order is the same as that of the internal sales order, and the transaction amount of the internal purchase order is the same as that of the internal sales order. Generate a purchase receipt in transit order. The total quantity in transit in the purchase receipt in transit order is equal to the quantity in the original document, and the total cost in transit is equal to the transaction amount of the internal sales order. The cost items are broken down and stored for cost allocation when the goods are actually received in the future. (3) The storage association method is as follows: all derived documents record the upstream document number field of the derived source, which points to the document number of the original document to ensure traceability; (4) The method for rolling back the transaction in case of failure is as follows: the five operations of creating an internal sales order, creating a sales delivery order, creating an internal purchase order, creating a purchase receipt in transit order, and storing the relationship are placed in the same transaction of the order database; when any of these five operations fails, all operations executed in the transaction are automatically rolled back, so that the order database is restored to the state before the start of the transaction, ensuring data consistency.
[0031] Step 5: Perform inbound cost calculation for internal purchase orders and inbound purchase receipts: break down the inbound cost into multiple cost items, calculate the amount of each cost item in the transaction currency, local currency, and purchase currency in parallel, and use the batch inbound deduction algorithm to determine the inbound cost for this time. In this embodiment, the calculation of warehousing costs in step 5 specifically includes: Step 51: For internal purchase orders, the warehousing cost is broken down into multiple cost items. Each cost item is stored independently in the cost center database and simultaneously records three currency fields: transaction currency amount, local currency amount, and purchase currency amount. The cost items include: item cost, first-mileage fee, customs duty, tax refund difference, and markup for each segment. Among them, the markup for each segment is numbered sequentially according to the transaction segment rules in the transaction chain. Each markup segment is stored and calculated as an independent cost item (e.g., markup_1, markup_2, ...). Step 52: Calculate the amount of each cost item in parallel under the transaction currency, base currency, and procurement currency, as follows: (1) Maintain an exchange rate table in advance, which includes the original currency, target currency, exchange rate, exchange rate type and effective date, wherein the exchange rate type includes accounting exchange rate and customs exchange rate; (2) Calculate the transaction amount of the internal purchase order in currency, using the formula: Transaction amount in currency = Original document cost × (1 + markup rate) × Current exchange rate; The original document cost is calculated using the markup factor; (3) Query the current exchange rate corresponding to the effective date of the current exchange rate type according to the business time and the main time zone, and calculate the base currency amount. The formula is: base currency amount = transaction currency amount × current exchange rate; (4) Obtain the purchase currency amount from the internal purchase order, which remains unchanged throughout the entire lifecycle and does not fluctuate with the exchange rate; (5) The amounts in three currencies for the same cost item are written in parallel to three independent fields in the same row of the cost center database, instead of being calculated serially, which improves processing efficiency; Step 53: Determine the cost of this inbound shipment using a batch-by-batch inbound deduction algorithm; details are as follows: (1) For a purchase receipt in transit, the total quantity in transit Q, the total cost in transit C, the quantity already received q_in, and the cost already received c_in are recorded; (2) When a new purchase receipt is received and the new receipt quantity is q_new, if q_in + q_new < Q, then the receipt cost = (C / Q) × q_new; if q_in + q_new = Q, then the receipt cost = C - c_in. The batch receipt deduction algorithm ensures that the rounding error is not accumulated, guaranteeing accurate matching of total cost. Step 6: Calculate outbound costs for internal sales orders and sales delivery orders: Lock out outbound costs based on the weighted average unit price of the current inventory, and simultaneously transfer the amount of each cost item in the transaction currency, base currency, and purchase currency. In this embodiment, the outbound cost calculation in step 6 specifically includes: Step 61: This is achieved by maintaining an inventory cost table, which records the weighted average unit price of each cost item in the current inventory according to three dimensions: owner identifier, warehouse identifier, and SKU code. The weighted average unit price is calculated as follows: Weighted average unit price = Total amount of current inventory for the cost item / Total quantity of current inventory. The cost items include the cost of goods, initial shipping costs, customs duties, tax refund differences, and surcharges for each segment. The formula for calculating the specific unit price of each cost item is as follows: (1) Unit cost of goods = Total cost of goods in the inventory cost table / Total quantity; (2) Unit price of first-leg cost = total amount of first-leg cost in the inventory cost table / total quantity; (3) Tariff unit price = Total tariff amount in the inventory cost table / Total quantity; (4) Tax refund difference unit price = total amount of tax refund difference in the inventory cost table / total quantity; (5) The unit price of each segment = the total amount of the segment's price increase / the total quantity; Step 62: Upon confirmation of outbound shipment, read the weighted average unit price of the SKU in the inventory cost table and calculate the total outbound cost and the outbound amount of each cost item using the following formula; details are as follows: Total outbound cost for each SKU = outbound quantity × weighted average unit price of the SKU; Cost of outbound items for each SKU = Quantity outbound × Unit cost of items; Outbound first-leg cost for each SKU = outbound quantity × first-leg cost unit price; Outbound tariff for each SKU = Outbound quantity × Tariff unit price; Tax refund difference for each SKU = outbound quantity × tax refund difference unit price; The markup for each SKU at each stage of outbound shipment = outbound quantity × markup unit price for each stage; Step 63: Calculate the transaction currency, local currency, and purchase currency for each cost item's outbound amount in parallel; details are as follows: Local currency amount = quantity issued × local currency weighted average unit price, local currency weighted average unit price = total local currency amount / total quantity in the inventory cost table; Purchase amount in currency = quantity issued × weighted average unit price in currency; weighted average unit price in currency = total purchase amount in currency / total quantity in the inventory cost table. The transaction amount is calculated in reverse from the base currency amount using the transaction exchange rate. The specific formula is: Transaction amount = Base currency amount / Transaction exchange rate.
[0032] Step 7: Update the cost balance of the inventory in real time based on the calculation results of inbound and outbound transactions; In this embodiment, step 7 specifically includes: after each inbound or outbound transaction is completed, the inventory cost table is updated immediately; wherein, the update process after inbound and the update process after outbound are executed separately, and the update method for each cost item is the same and completed independently; (1) The update process after warehousing is as follows: New total quantity = original total quantity + warehousing quantity, new total cost item amount = original total cost item amount + the amount of this cost item in this warehousing, new cost item unit price = new total cost item amount / new total quantity; specifically as follows: The total cost of new items = the total cost of original items + the cost of items put into storage; the unit cost of new items = the total cost of new items / the total quantity of new items. New first-leg cost total amount = original first-leg cost total amount + warehousing first-leg cost amount, new first-leg cost unit price = new first-leg cost total amount / new total quantity; New tariff total amount = original tariff total amount + tariff amount incurred into the warehouse; new tariff unit price = new tariff total amount / new total quantity. New tax refund difference total amount = original tax refund difference total amount + warehousing tax refund difference total amount, new tax refund difference unit price = new tax refund difference total amount / new total quantity; The total price increase for each new segment = the total price increase for each original segment + the total price increase for each segment upon entry into the warehouse; the unit price of the price increase for each new segment = the total price increase for each new segment / the total quantity of the new segment. (2) The update process after the goods are shipped out is as follows: New total quantity = Original total quantity - Quantity shipped out, New total cost item amount = Original total cost item amount - Amount of this cost item shipped out, New unit price of cost item = New total cost item amount / New total quantity; Specifically as follows: Total cost of new items = Total cost of original items - Cost of items issued from the warehouse; Unit cost of new items = Total cost of new items / Total quantity of new items. New total first-leg cost = Original total first-leg cost - Outbound first-leg cost; New first-leg cost unit price = New total first-leg cost / New total quantity. New total tariff amount = original total tariff amount - outbound tariff amount; new tariff unit price = new total tariff amount / new total quantity. New total tax refund difference = original total tax refund difference - outbound tax refund difference; new tax refund difference unit price = new total tax refund difference / new total quantity. The total amount of the new price increase for each segment = the total amount of the original price increase for each segment - the total amount of the price increase for each segment upon delivery; the unit price of the new price increase for each segment = the total amount of the new price increase for each segment / the total quantity. When the total quantity becomes zero after shipment, the unit price will be retained as the last unit price before shipment.
[0033] Step 8: Generate and save the corresponding transaction records for the detailed status before and after each inventory change.
[0034] In this embodiment, step 8 specifically includes: Generate a transaction record for each inventory change and store the transaction record in the inventory change transaction record table; each transaction record contains the following fields: quantity before change, quantity after change, total amount of each cost item before change, total amount of each cost item after change, unit price of each cost item before change, unit price of each cost item after change, associated document number, SKU code, warehouse identifier, and business time. The total amount of each cost item before the change includes the total cost of goods before the change, the total amount of first-leg expenses before the change, the total amount of customs duties before the change, the total amount of tax refund difference before the change, and the total amount of price increase for each segment before the change. The total amount of each cost item after the change includes the total amount of the changed item cost, the total amount of the changed first-leg expenses, the total amount of the changed customs duties, the total amount of the changed tax refund difference, and the total amount of the changed price increase for each segment. The unit prices of each cost item before the change include the unit price of the item cost before the change, the unit price of the first leg fee before the change, the unit price of the customs duty before the change, the unit price of the tax refund difference before the change, and the unit price of each segment's surcharge before the change. The revised unit prices for each cost item include the revised unit price for the cost of the goods, the revised unit price for the initial leg of the journey, the revised unit price for customs duties, the revised unit price for the tax refund difference, and the revised unit price for each segment's additional charges.
[0035] Step 9: Send the generated transaction records to the financial voucher system. The financial voucher system performs at least one of the following based on the transaction records: cost variance analysis, audit traceability analysis, voucher generation, financial statement management, and financial reconciliation management. The cost variance analysis specifically involves: finance personnel querying the inventory cost composition at any point in time based on the transaction records, comparing the cost differences of different batches of goods received, and identifying the reasons for abnormal cost fluctuations (such as abnormally high first-haul costs for a certain batch). The audit traceability analysis specifically involves: when a cost error occurs, reverse calculations are performed using transaction records to identify the specific documents and operations in which the error occurred, which are then used for data repair. Financial statement management specifically involves extracting data from transaction records by time interval and summarizing it by purchase currency to generate financial statements without the need for recalculation. Financial reconciliation management specifically involves generating vouchers based on transaction records to ensure consistency between cost data on the business and financial sides.
[0036] The above description is only a part of the embodiments of the present invention and does not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made based on the content of the present invention specification and drawings, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of the present invention.
Claims
1. A refined cost accounting method for cross-border multi-entity e-commerce, characterized in that, Specifically, the steps include the following: Step 1: Receive the original documents, parse them, and extract the key information fields; Step 2: Determine whether the current original document belongs to an inter-company transaction based on the key information fields. If yes, proceed to Step 3; otherwise, proceed to Step 5. Step 3: Locate the preset transaction link and determine whether the current original document matches the transaction link segment rule based on the key information fields. Step 4: When the transaction link segment rule is hit, a derivative document is generated. The derivative document includes at least an internal sales order, a sales delivery order, an internal purchase order, and a purchase receipt in transit order. Step 5: Perform inbound cost calculation for internal purchase orders and inbound purchase receipts: break down the inbound cost into multiple cost items, calculate the amount of each cost item in the transaction currency, local currency, and purchase currency in parallel, and use the batch inbound deduction algorithm to determine the inbound cost for this time. Step 6: Calculate outbound costs for internal sales orders and sales delivery orders: Lock out outbound costs based on the weighted average unit price of the current inventory, and simultaneously transfer the amount of each cost item in the transaction currency, base currency, and purchase currency. Step 7: Update the cost balance of the inventory in real time based on the calculation results of inbound and outbound transactions; Step 8: Generate and save the corresponding transaction records for the detailed status before and after each inventory change.
2. The refined cost accounting method for cross-border multi-entity e-commerce as described in claim 1, characterized in that, Step 1 specifically includes: Step 11: When a real inbound or outbound transaction occurs, the ERP system sends the original document to the cost center system. The original document is in JSON or XML format. Step 12: The cost center system receives original documents via API interface by listening for messages; Step 13: The cost center system parses the original documents, extracts key information fields from the original documents, and stores them in the original document table of the cost center database; The key information fields include at least the document type, business type, warehouse identifier, owner identifier, SKU code, quantity, business time, and associated document number; when the document type is a sales outbound order, the key information fields also include the sales account identifier. The document types include purchase receipt, transfer order, and sales order, which are used to identify whether the original document is a receipt or an order. The business types include purchase receipt, transfer receipt, and sales receipt, which are used to identify specific business scenarios to match cost calculation rules; The warehouse identifier is used to obtain the warehouse type and the warehouse where the goods are actually stored by associating with the warehouse master data table, and then associate it with the cargo owner entity to which the warehouse belongs; The cargo owner identifier is used to identify the entity to which the cargo is owned. It is directly provided by the ERP system based on the cargo owner entity and is used to determine whether a change of cargo owner entity has occurred. The SKU code is used to uniquely identify products and serves as a basic dimension for cost accounting. The quantity refers to the quantity of goods entering and leaving the warehouse this time, which is used for cost calculation and inventory quantity updates; The business time refers to the actual time when the business occurs, used for querying exchange rates; The associated document number is used to trace the source of the business and associate it with in-transit orders; The sales account identifier serves as a query index for the mapping table between stores and entities, allowing users to query the accounting entity corresponding to the sales account.
3. The refined cost accounting method for cross-border multi-entity e-commerce as described in claim 2, characterized in that, Step 2 specifically includes: Step 21: Extract the document type and business type from the original document table. Determine whether the current original document belongs to an inter-company transaction based on the document type and business type. If the document type is a transfer order and the business type is a transfer order, or if the document type is a sales order and the business type is a sales order, proceed to step 22. If the document type is other types, determine that the original document is a transfer transaction within the same entity, which belongs to a non-inter-company transaction, and proceed to step 5. Step 22: Identify inter-company transactions using different identification rules based on document type, as detailed below: For transfer and outbound orders, a transfer and outbound identification rule is adopted, which specifically includes the following steps: (1) Extract the warehouse identifier from the original document table, and query the warehouse master data table through the warehouse identifier to obtain the warehouse type and the cargo owner to which the warehouse belongs; the warehouse type includes physical warehouses and virtual warehouses, and the virtual warehouses include virtual transit warehouses and virtual forward warehouses; (2) Extract the associated document number from the original document table as the transfer outbound order number, and use the transfer outbound order number to call the ERP interface to obtain the transfer outbound order information or query the local cached transfer outbound order information; determine whether the transfer outbound order has a transaction link identifier based on the transfer outbound order information. (3) If the warehouse type is not a virtual warehouse and there is a transaction link identifier, it is determined to be an inter-company transaction; if the warehouse type is a virtual warehouse or there is no transaction link identifier, the original document is determined to be a transfer transaction within the same entity, which is a non-inter-company transaction, and proceed to step 5. For sales delivery orders, a sales delivery identification rule is used, which specifically includes the following steps: (1) Extract the owner's main identifier from the original document table; (2) Extract the sales account identifier from the original document table, query the mapping relationship table between the store and the entity through the sales account identifier, and obtain the accounting entity identifier corresponding to the sales account identifier; (3) Determine whether the owner's identifier and the accounting entity identifier are consistent. If yes, the original document is determined to be a normal sales transaction and belongs to a non-inter-company transaction. Proceed to step 5. If no, the original document is determined to be an inter-company transaction. Proceed to step 3.
4. The refined cost accounting method for cross-border multi-entity e-commerce as described in claim 3, characterized in that, Step 3 specifically includes: Step 31: Pre-configure the transaction chain. Each transaction chain is stored in the transaction master data table in JSON format. The core fields of each transaction chain include at least: transaction chain identifier, ordered node array, and node segment rule array. Each node in the ordered node array contains a node sequence number and a node subject ID. Each node segment rule in the node segment rule array contains a seller subject ID, a buyer subject ID, a markup rate, a transaction currency, a markup factor, and an identifier indicating whether a tax refund difference is involved. Step 32: After determining that the original document is an inter-company transaction, locate the preset transaction link based on the transaction link identifier; the specific method is as follows: (1) Query the warehouse master data table based on the warehouse identifier to obtain the corresponding cargo owner entity as the current entity; (2) Obtain the counterparty entity according to the document type; for transfer outbound order, obtain the entity to which the destination warehouse belongs from the transfer outbound order information as the counterparty entity; for sales outbound order, obtain the accounting entity to which the corresponding accounting entity identifier belongs according to the sales account identifier as the counterparty entity. (3) Traverse all configured transaction links and search for a transaction link whose node order includes adjacent segments from the current entity to the counterparty entity, i.e., the seller entity to which the seller entity ID belongs is the current entity and the buyer entity to which the buyer entity ID belongs is the counterparty entity; if it exists, the transaction link segment rule is hit, the markup rate and transaction currency in the transaction link segment rule are recorded, and step 4 is entered; if it does not exist, the original document is determined to be a transfer transaction within the same entity, which belongs to a non-company transaction, and step 5 is entered.
5. The refined cost accounting method for cross-border multi-entity e-commerce as described in claim 4, characterized in that, Step 4 specifically includes: When a transaction link segment rule is hit, the derivative document generation engine is triggered. This derivative document generation engine performs the following operations within a transaction in the same order database: creating internal sales orders and sales delivery orders, creating internal purchase orders and purchase receipts in transit orders, storing related relationships, and rolling back transactions if operations fail. (1) The method for creating internal sales orders and sales delivery slips is as follows: Generate a new internal sales order. The order number of the internal sales order is formed by concatenating the prefix GISSO, the current date, and the serial number. The seller in the internal sales order is the current entity, the buyer is the counterparty, and the transaction currency is taken from the transaction currency of the matching transaction link segment rule in the transaction link. Calculate the transaction amount in the internal sales order. Generate a corresponding sales delivery order, which is associated with the internal sales order. The delivery quantity is consistent with the quantity in the original document, and the delivery cost is determined using the algorithm for calculating delivery costs. (2) The method for creating internal purchase orders and purchase receipts in transit is as follows: Generate a new internal purchase order. The order number of the internal purchase order is composed of the prefix GISPO, the current date, and the serial number. The seller of the internal purchase order is the current entity, and the buyer is the counterparty. The transaction currency of the internal purchase order is the same as that of the internal sales order, and the transaction amount of the internal purchase order is the same as that of the internal sales order. Generate a purchase receipt in transit order. The total quantity in transit in the purchase receipt in transit order is equal to the quantity in the original document, and the total cost in transit is equal to the transaction currency amount of the internal sales order. Then, break down and store each cost item. (3) The storage association method is as follows: all derived documents record the upstream document number field of the derived source, which points to the document number of the original document; (4) The method for rolling back the transaction in case of failure is as follows: the five operations of creating an internal sales order, creating a sales delivery order, creating an internal purchase order, creating a purchase receipt in transit order, and storing the relationship are placed in the same transaction of the order database; when any of these five operations fails, all operations executed in the transaction are automatically rolled back, so that the order database is restored to the state before the start of the transaction.
6. The refined cost accounting method for cross-border multi-entity e-commerce as described in claim 2, characterized in that, The calculation of warehousing costs in step 5 specifically includes: Step 51: For internal purchase orders, the warehousing cost is broken down into multiple cost items. Each cost item is stored independently in the cost center database and simultaneously records three currency fields: transaction currency amount, local currency amount, and purchase currency amount. The cost items include: item cost, first-mileage fee, customs duty, tax refund difference, and markups for each segment. The markups for each segment are numbered sequentially according to the transaction segment rules in the transaction chain, and each markup is stored and calculated as an independent cost item. Step 52: Calculate the amount of each cost item in parallel under the transaction currency, base currency, and procurement currency, as follows: (1) Maintain an exchange rate table in advance, which includes the original currency, target currency, exchange rate, exchange rate type and effective date, wherein the exchange rate type includes accounting exchange rate and customs exchange rate; (2) Calculate the transaction amount of the internal purchase order in currency, using the formula: Transaction amount in currency = Original document cost × (1 + markup rate) × Current exchange rate; The original document cost is calculated using the markup factor; (3) Query the current exchange rate corresponding to the effective date of the current exchange rate type according to the business time and the main time zone, and calculate the base currency amount. The formula is: base currency amount = transaction currency amount × current exchange rate; (4) Obtain the purchase currency amount from the internal purchase order; (5) Write the amounts in three currencies for the same cost item into three independent fields in the same row of the cost center database in parallel; Step 53: Determine the cost of this inbound shipment using a batch-by-batch inbound deduction algorithm; details are as follows: (1) For a purchase receipt in transit, the total quantity in transit Q, the total cost in transit C, the quantity already received q_in, and the cost already received c_in are recorded; (2) When a new purchase receipt is received and the new receipt quantity is q_new, if q_in+q_new<Q, then the receipt cost = (C / Q) × q_new; if q_in+q_new=Q, then the receipt cost = C-c_in.
7. The refined cost accounting method for cross-border multi-entity e-commerce as described in claim 1, characterized in that, The calculation of outbound costs in step 6 specifically includes: Step 61: This is achieved by maintaining an inventory cost table, which records the weighted average unit price of each cost item in the current inventory according to three dimensions: owner identifier, warehouse identifier, and SKU code. The weighted average unit price is calculated as follows: Weighted average unit price = Total amount of current inventory for the cost item / Total quantity of current inventory. The cost items include the cost of goods, initial shipping costs, customs duties, tax refund differences, and surcharges for each segment. The formula for calculating the specific unit price of each cost item is as follows: (1) Unit cost of goods = Total cost of goods in the inventory cost table / Total quantity; (2) Unit price of first-leg cost = total amount of first-leg cost in the inventory cost table / total quantity; (3) Tariff unit price = Total tariff amount in the inventory cost table / Total quantity; (4) Tax refund difference unit price = total amount of tax refund difference in the inventory cost table / total quantity; (5) The unit price of each segment = the total amount of the segment's price increase / the total quantity; Step 62: Upon confirmation of outbound shipment, read the weighted average unit price of the SKU in the inventory cost table and calculate the total outbound cost and the outbound amount of each cost item using the following formula; details are as follows: Total outbound cost for each SKU = outbound quantity × weighted average unit price of the SKU; Cost of outbound items for each SKU = Quantity outbound × Unit cost of items; Outbound first-leg cost for each SKU = outbound quantity × first-leg cost unit price; Outbound tariff for each SKU = Outbound quantity × Tariff unit price; Tax refund difference for each SKU = outbound quantity × tax refund difference unit price; The markup for each SKU at each stage of outbound shipment = outbound quantity × markup unit price for each stage; Step 63: Calculate the transaction currency, local currency, and purchase currency for each cost item's outbound amount in parallel; details are as follows: Local currency amount = quantity issued × local currency weighted average unit price, local currency weighted average unit price = total local currency amount / total quantity in the inventory cost table; Purchase amount in currency = quantity issued × weighted average unit price in currency; weighted average unit price in currency = total purchase amount in currency / total quantity in the inventory cost table. The transaction amount is calculated in reverse from the base currency amount using the transaction exchange rate. The specific formula is: Transaction amount = Base currency amount / Transaction exchange rate.
8. The refined cost accounting method for cross-border multi-entity e-commerce as described in claim 1, characterized in that, Step 7 specifically includes: after each inbound or outbound transaction is completed, the inventory cost table is updated immediately; wherein, the update process after inbound and the update process after outbound are executed separately, and the update method for each cost item is the same and completed independently; (1) The update process after warehousing is as follows: New total quantity = original total quantity + warehousing quantity, new total cost item amount = original total cost item amount + the amount of this cost item in this warehousing, new cost item unit price = new total cost item amount / new total quantity; specifically as follows: The total cost of new items = the total cost of original items + the cost of items put into storage; the unit cost of new items = the total cost of new items / the total quantity of new items. New first-leg cost total amount = original first-leg cost total amount + warehousing first-leg cost amount, new first-leg cost unit price = new first-leg cost total amount / new total quantity; New tariff total amount = original tariff total amount + tariff amount incurred into the warehouse; new tariff unit price = new tariff total amount / new total quantity. New tax refund difference total amount = original tax refund difference total amount + warehousing tax refund difference total amount, new tax refund difference unit price = new tax refund difference total amount / new total quantity; The total price increase for each new segment = the total price increase for each original segment + the total price increase for each segment upon entry into the warehouse; the unit price of the price increase for each new segment = the total price increase for each new segment / the total quantity of the new segment. (2) The update process after the goods are shipped out is as follows: New total quantity = Original total quantity - Quantity shipped out, New total cost item amount = Original total cost item amount - Amount of this cost item shipped out, New unit price of cost item = New total cost item amount / New total quantity; Specifically as follows: Total cost of new items = Total cost of original items - Cost of items issued from the warehouse; Unit cost of new items = Total cost of new items / Total quantity of new items. New total first-leg cost = Original total first-leg cost - Outbound first-leg cost; New first-leg cost unit price = New total first-leg cost / New total quantity. New total tariff amount = original total tariff amount - outbound tariff amount; new tariff unit price = new total tariff amount / new total quantity. New total tax refund difference = original total tax refund difference - outbound tax refund difference; new tax refund difference unit price = new total tax refund difference / new total quantity. The total amount of the new price increase for each segment = the total amount of the original price increase for each segment - the total amount of the price increase for each segment upon delivery; the unit price of the new price increase for each segment = the total amount of the new price increase for each segment / the total quantity. When the total quantity becomes zero after shipment, the unit price will be retained as the last unit price before shipment.
9. A refined cost accounting method for cross-border multi-entity e-commerce as described in claim 1, characterized in that, Step 8 specifically includes: Generate a transaction record for each inventory change and store the transaction record in the inventory change transaction record table; each transaction record contains the following fields: quantity before change, quantity after change, total amount of each cost item before change, total amount of each cost item after change, unit price of each cost item before change, unit price of each cost item after change, associated document number, SKU code, warehouse identifier, and business time. The total amount of each cost item before the change includes the total cost of goods before the change, the total amount of first-leg expenses before the change, the total amount of customs duties before the change, the total amount of tax refund difference before the change, and the total amount of price increase for each segment before the change. The total amount of each cost item after the change includes the total amount of the changed item cost, the total amount of the changed first-leg expenses, the total amount of the changed customs duties, the total amount of the changed tax refund difference, and the total amount of the changed price increase for each segment. The unit prices of each cost item before the change include the unit price of the item cost before the change, the unit price of the first leg fee before the change, the unit price of the customs duty before the change, the unit price of the tax refund difference before the change, and the unit price of each segment's surcharge before the change. The revised unit prices for each cost item include the revised unit price for the cost of the goods, the revised unit price for the initial leg of the journey, the revised unit price for customs duties, the revised unit price for the tax refund difference, and the revised unit price for each segment's additional charges.
10. The refined cost accounting method for cross-border multi-entity e-commerce as described in claim 1, characterized in that, After step 8, the method further includes: sending the generated transaction record to the financial voucher system, wherein the financial voucher system performs at least one of the following based on the transaction record: cost difference analysis, audit traceability analysis, voucher generation, financial statement management and financial reconciliation management; The cost variance analysis specifically involves: finance personnel querying the inventory cost composition at any point in time based on the transaction records, comparing the cost differences of different batches of goods received, and identifying the reasons for abnormal cost fluctuations. The audit traceability analysis specifically involves: when a cost error occurs, reverse calculations are performed using transaction records to identify the specific documents and operations in which the error occurred, which are then used for data repair. Financial statement management specifically involves extracting data from transaction records by time interval and summarizing it by purchase currency to generate financial statements. Financial reconciliation management specifically involves generating vouchers based on transaction records.