Data fusion method and system for multi-source heterogeneous trade data

Abstract

The application provides a data fusion method and system for multi-source heterogeneous trade data, and relates to the technical field of trade data processing. First, the initial data set is obtained, and the trade elements are extracted to generate a trade element set; second, the transaction main line is generated according to the contract number, invoice number and buyer-seller main body; the transportation main line is generated along the transaction main line, the supervision main line is generated along the transportation main line, and the payment number is classified into the settlement main line to generate a trade event segment; then, the goods delivery event, the document circulation event, the supervision disposal event and the fund settlement event are divided according to the initial data source and the business occurrence time to generate a fusion data record. The technical scheme provided by the application merges multi-source heterogeneous trade data layer by layer through the transaction main line, the transportation main line, the supervision main line and the settlement main line, realizes the trade event fusion in the scenarios of box transportation, batch declaration and payment, and improves the data attribution accuracy and traceability completeness of the same trade matter.

Description

Technical Field

[0001] This application relates to the field of trade data processing technology, and in particular to a data fusion method and system for multi-source heterogeneous trade data. Background Technology

[0002] Cross-border trade typically involves various types of data, including customs declarations, bills of lading, commercial invoices, contracts, inspection and quarantine documents, port operations, and cross-border payments. These data originate from different entities at different stages of the business process, resulting in inconsistent field naming, numbering, time recording, and cargo splitting methods. A single contract may correspond to multiple invoices, a single bill of lading may correspond to multiple container numbers, and the same container number may correspond to multiple declaration numbers or multiple inspection and quarantine numbers. Furthermore, cross-border payments may occur after goods delivery or regulatory processing.

[0003] Current trade data processing methods often rely on single numbers or fixed fields for association. When the contract number is not recorded in the invoice, there is a lack of direct reference between the bill of lading and the declaration data, or when goods are transported in separate containers or declared in batches, it is easy to separate data belonging to the same trade matter or merge data from different trade matters together. Summary of the Invention

[0004] The purpose of this application is to provide a data fusion method and system for multi-source heterogeneous trade data, which is used to form a fused data record of the same trade matter when there are missing numbers, inconsistent numbers, separate container transportation, separate declarations and separate payments in the multi-source trade data.

[0005] Firstly, this application provides a data fusion method for multi-source heterogeneous trade data, including:

[0006] An initial data set is obtained, and trade elements are extracted from the initial data set to generate a trade element set. The initial data set includes customs declaration data, bill of lading data, commercial invoice data, contract data, inspection and quarantine data, port operation data, and cross-border payment data. The trade elements include the name of the goods, the quantity of the goods, the buyer and seller, the carrier, the port of loading, the port of destination, the container number, the contract number, the invoice number, the bill of lading number, the declaration number, the inspection and quarantine number, the inspection and quarantine time, the payment number, and the time of the transaction.

[0007] A transaction timeline is generated based on the contract number, the invoice number, and the reference relationships between the buyer and seller.

[0008] The bill of lading number and container number are located along the main transaction line, and the transportation main line is generated based on the bill of lading number, the container number, the carrier relationship between the port of loading and the port of destination;

[0009] The declaration number and inspection and quarantine number are located along the main transportation route, and a supervision route is generated based on the batch correspondence between the cargo name, cargo quantity and the container number;

[0010] Based on the buyer and seller entities, goods names, goods quantities, and business occurrence times that are interconnected in the transaction main line, the transportation main line, and the regulatory main line, the payment number is assigned to the settlement main line to generate a trade event fragment;

[0011] Based on the initial data source and business occurrence time corresponding to each trade element in the aforementioned trade event segment, the events are divided into goods delivery events, document circulation events, regulatory handling events, and fund settlement events.

[0012] Based on the chronological order of the goods delivery event, the document transfer event, the regulatory handling event, and the fund settlement event, a fused data record is generated.

[0013] Optionally, a transaction thread is generated based on the contract number, the invoice number, and the reference relationship between the buyer and seller, including:

[0014] Select a contract number from the set of trade elements as the starting point of the transaction;

[0015] Find the invoice number, buyer and seller, goods name, and goods quantity that appear together with the contract number in the set of trade elements;

[0016] When the invoice number does not record the contract number, the corresponding invoice number is assigned to the transaction starting point based on the same buyer and seller, goods name, goods quantity, and transaction time to generate the transaction main line.

[0017] Optionally, the bill of lading number and container number are searched along the main transaction line, and a transportation main line is generated based on the bill of lading number, the container number, and the carrier relationship between the port of loading and the port of destination, including:

[0018] Read the goods name, quantity, buyer and seller, and invoice number along the main transaction line;

[0019] Search within the set of trade elements for the bill of lading number that appears together with the invoice number, the goods name, and the buyer and seller;

[0020] Based on the bill of lading number, the corresponding container number, carrier, port of loading, and port of destination can be found in the set of trade elements.

[0021] When the same bill of lading number corresponds to multiple container numbers, container transport segments are formed according to the cargo name and quantity recorded in the container number;

[0022] Based on the bill of lading number and the container number, the loading time and arrival time are determined from the port operation data;

[0023] The bill of lading number, container number, port of loading, port of destination, loading time, and arrival time are combined to generate the main transportation route.

[0024] Optionally, the declaration number and inspection and quarantine number are searched along the main transportation route, and a regulatory main line is generated based on the batch correspondence between the cargo name, cargo quantity, and container number, including:

[0025] Read the bill of lading number, container number, cargo name, and cargo quantity along the main transportation route;

[0026] Search the set of trade elements for the declaration number that appears together with the bill of lading number or the container number;

[0027] Based on the declaration number, find the corresponding inspection and quarantine number and inspection and quarantine time in the set of trade elements;

[0028] When the same container number corresponds to multiple declaration numbers, the container number shall be split into multiple declaration segments according to the cargo name and cargo quantity;

[0029] The regulatory mainline is generated by combining the application number, the application time, the inspection and quarantine number, and the application segment.

[0030] Optionally, based on the buyer and seller entities, goods names, goods quantities, and transaction times that are interconnected in the transaction mainline, the transportation mainline, and the regulatory mainline, the payment number is assigned to the settlement mainline to generate a trade event fragment, including:

[0031] Read the buyer and seller entities, goods name, goods quantity, and contract number from the transaction mainline;

[0032] Read the bill of lading number, container number, port of loading, port of destination, and carrier from the main transportation route;

[0033] Read the declaration number and inspection and quarantine number from the aforementioned regulatory framework;

[0034] Search the set of trade elements for the payment number that records the buyer and seller and corresponds to the name or quantity of goods.

[0035] The transaction mainline, the transportation mainline, the regulatory mainline, and the assigned payment number are combined into trade event fragments according to the time of the business occurrence.

[0036] Optionally, based on the initial data source and business occurrence time corresponding to each trade element in the trade event segment, the events are divided into goods delivery events, document circulation events, regulatory handling events, and fund settlement events, including:

[0037] Trade elements derived from contract data and commercial invoice data in the aforementioned trade event fragments are categorized into the document circulation event;

[0038] The trade elements derived from bill of lading data and port operation data in the aforementioned trade event fragments are classified into the cargo delivery event;

[0039] Trade elements derived from customs declaration data and inspection and quarantine data in the aforementioned trade event fragments are classified into the aforementioned regulatory handling events;

[0040] Trade elements derived from cross-border payment data in the aforementioned trade event fragments are categorized into the aforementioned fund settlement events.

[0041] Optionally, based on the chronological order of the goods delivery event, the document transfer event, the regulatory handling event, and the fund settlement event, a fused data record is generated, including:

[0042] Extract the contract number, invoice number, and business occurrence time from the document circulation event. Place the trade element that records the contract number before the trade element that records the invoice number, and arrange multiple invoice numbers that record the same contract number according to the business occurrence time to determine the document reference order.

[0043] Extract the bill of lading number, container number, port of loading, port of destination, and transaction time from the cargo delivery event. Place the transaction time of the corresponding port of loading before the transaction time of the corresponding port of destination. Arrange multiple container numbers that share the same bill of lading number according to the transaction time to determine the cargo carrying order.

[0044] Extract the declaration number, inspection and quarantine number, and business occurrence time from the aforementioned regulatory handling event. Place the trade element that records the declaration number before the trade element that records the inspection and quarantine number, and arrange multiple inspection and quarantine numbers that record the same declaration number according to the business occurrence time to determine the order of regulatory handling.

[0045] Extract the payment number, buyer and seller, goods name, goods quantity, and transaction time from the fund settlement event. Arrange multiple payment numbers that correspond to the same buyer and seller, the same goods name, and the same goods quantity according to the transaction time to determine the settlement order.

[0046] The fused data record is generated by connecting the document transfer event, the goods delivery event, the regulatory disposal event, and the fund settlement event according to the document reference order, the goods shipment order, the regulatory disposal event, and the fund settlement event.

[0047] Secondly, this application provides a data fusion system for multi-source heterogeneous trade data, including:

[0048] The extraction module is used to obtain an initial data set and extract trade elements from the initial data set to generate a trade element set. The initial data set includes customs declaration data, bill of lading data, commercial invoice data, contract data, inspection and quarantine data, port operation data, and cross-border payment data. The trade elements include goods name, goods quantity, buyer and seller, carrier, port of loading, port of destination, container number, contract number, invoice number, bill of lading number, declaration number, inspection and quarantine number, inspection and quarantine time, payment number, and transaction occurrence time.

[0049] The first generation module generates a transaction mainline based on the contract number, the invoice number, and the reference relationship between the buyer and seller.

[0050] The second generation module is used to find the bill of lading number and container number along the main transaction line, and generate the main transportation line based on the bill of lading number, the container number, the carrier relationship between the port of loading and the port of destination;

[0051] The third generation module is used to search for the declaration number and inspection and quarantine number along the main transportation line, and generate the supervision line according to the batch correspondence between the cargo name, cargo quantity and the container number;

[0052] The fourth generation module is used to assign the payment number to the settlement line and generate trade event fragments based on the buyer and seller entities, goods names, goods quantities and business occurrence times that are interconnected in the transaction line, the transportation line and the regulatory line.

[0053] The segmentation module is used to segment goods delivery events, document circulation events, regulatory handling events, and fund settlement events according to the initial data source and business occurrence time of each trade element in the trade event segment.

[0054] The fifth generation module is used to generate fused data records based on the chronological relationship between the goods delivery event, the document circulation event, the regulatory disposal event, and the fund settlement event.

[0055] Thirdly, this application provides a computing device, including a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are invoked and executed by the processing component to implement a data fusion method for multi-source heterogeneous trade data as described in the first aspect above.

[0056] Fourthly, this application provides a computer storage medium storing a computer program, which, when executed by a computer, implements a data fusion method for multi-source heterogeneous trade data as described in the first aspect.

[0057] This application does not directly merge multi-source data with a single number. Instead, it first forms a transaction mainline based on contract number, invoice number, and buyer and seller entities, and then forms a transportation mainline, a regulatory mainline, and a settlement mainline layer by layer along the transaction mainline, so that the trade data integration process conforms to the business connection relationship between contracts, transportation, supervision, and payment.

[0058] This application handles the situation where the same bill of lading number corresponds to multiple container numbers in the transportation mainline, the situation where the same container number corresponds to multiple declaration numbers in the supervision mainline, and the relationship between payment number and the buyer / seller, goods name, goods quantity and transaction time in the settlement mainline, enabling continuous organization of trade data for containerized transportation, batch declaration and payment.

[0059] The fusion data records generated by this application retain the chronological relationship between goods delivery events, document circulation events, regulatory disposal events, and fund settlement events, which facilitates subsequent traceability of trade matters, anomaly detection, and business verification.

[0060] These or other aspects of this application will become more apparent in the following description of the embodiments. Attached Figure Description

[0061] To more clearly illustrate the technical solutions in this application 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 some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0062] Figure 1 This is a schematic diagram of the overall process of the data fusion method for multi-source heterogeneous trade data provided in the embodiments of this application.

[0063] Figure 2 This is a schematic diagram of the transaction mainline generation process provided in the embodiments of this application.

[0064] Figure 3This is a schematic diagram of the transportation mainline generation process provided in the embodiments of this application.

[0065] Figure 4 This is a schematic diagram of the regulatory mainline generation process provided in the embodiments of this application.

[0066] Figure 5 This is a schematic diagram of the trade event fragment generation process provided in the embodiments of this application.

[0067] Figure 6 This is a schematic diagram of the event division process provided in the embodiments of this application.

[0068] Figure 7 This is a schematic diagram of the fusion data record generation process provided in the embodiments of this application.

[0069] Figure 8 This is a schematic diagram of the structure of the data fusion system provided in the embodiments of this application. Detailed Implementation

[0070] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are used to illustrate the implementation of this application and are not intended to limit the scope of protection of this application.

[0071] This embodiment provides a data fusion method for multi-source heterogeneous trade data. Multi-source heterogeneous trade data refers to trade data originating from different trade business stages and recorded in different formats. The initial dataset is a set of data composed of customs declaration data, bill of lading data, commercial invoice data, contract data, inspection and quarantine data, port operation data, and cross-border payment data. Trade elements refer to the basic content extracted from the initial dataset that can describe the attribution relationship of trade matters, including the name of goods, quantity of goods, buyer and seller, carrier, port of loading, port of destination, container number, contract number, invoice number, bill of lading number, declaration number, inspection and quarantine number, inspection and quarantine time, payment number, and transaction occurrence time.

[0072] The "business occurrence time" is a collective term for the time when the corresponding business node occurs across various data sources. In contract data, the business occurrence time corresponds to the contract formation time; in commercial invoice data, it corresponds to the invoicing time; in port operation data, it corresponds to the loading or arrival time; in customs declaration data, it corresponds to the declaration time; in inspection and quarantine data, it corresponds to the inspection and quarantine time; and in cross-border payment data, it corresponds to the payment time. The loading and arrival times, as the business occurrence times corresponding to port operation data, are written into the trade element set, while the declaration time, as the business occurrence time corresponding to customs declaration data, is also written into the trade element set.

[0073] like Figure 1As shown, the method in this embodiment includes S10 to S70.

[0074] S10: Obtain the initial data set, extract trade elements from the initial data set to generate a trade element set.

[0075] In S10, the implementing entity acquires customs declaration data, bill of lading data, commercial invoice data, contract data, inspection and quarantine data, port operation data, and cross-border payment data, and extracts trade elements from these data. The implementing entity records each trade element along with its corresponding initial data source so that events can be segmented based on the initial data source later. The initial data source refers to which type of data—customs declaration data, bill of lading data, commercial invoice data, contract data, inspection and quarantine data, port operation data, or cross-border payment data—the trade element originates from.

[0076] The trade element set is not simply a collection of field names, but a set of records containing trade elements, initial data sources, and the time of the transaction. After the executing entity generates the trade element set, subsequent generation of the transaction mainline, transportation mainline, regulatory mainline, and settlement mainline all read data from the trade element set, avoiding the use of different data standards in different steps.

[0077] S20: Generate the transaction mainline based on the contract number, invoice number, and the reference relationship between the buyer and seller.

[0078] A transaction thread refers to a data chain that starts with a trade element containing a contract number and includes invoice numbers, buyer and seller entities, goods names, and quantities within the same transaction scope. A referencing relationship refers to a trade element that simultaneously records both a contract number and an invoice number, or a trade element corresponding to an invoice number that shares a corresponding buyer and seller entity, the same goods name, mutually received goods quantities, and the time of the mutually received transactions with the corresponding trade element. Buyer-seller correspondence means that the buyer in the contract data corresponds to the buyer or payer in the commercial invoice data, and the seller in the contract data corresponds to the seller or payee in the commercial invoice data.

[0079] like Figure 2 As shown, S20 includes S21 to S24.

[0080] S21: The executing entity selects a trade element containing a contract number from the set of trade elements as the starting point of the transaction. The starting point of the transaction is not a single contract number, but a trade element that includes the contract number and, together with the contract number, the buyer and seller, the name of the goods, and the quantity of the goods.

[0081] S22: The executing entity searches for invoice numbers, buyer and seller entities, goods names, and goods quantities that appear together with the contract number in the set of trade elements.

[0082] S23: When the invoice number does not record the contract number, the executing entity shall assign the corresponding invoice number to the transaction starting point according to the transaction assignment rules. The transaction assignment rules are shown in the table below.

[0083] R11 Invoice number and contract number appear together in the same trade element Invoice number will be assigned to the transaction origin. R12 The invoice number does not record the contract number, but the buyer and seller correspond, the goods names are the same, and the quantities of goods match the quantities at the start of the transaction. Invoice number will be assigned to the transaction origin. R13 The invoice number does not record the contract number, but the buyer and seller correspond, the goods names are the same, and the quantity of goods corresponds to the quantity of goods in the initial transaction record. Sub-item invoice numbers used as the starting point of the transaction R14 The buyer and seller do not correspond, or the names of the goods are different. Invoice number not included in the transaction start point

[0084] Of the aforementioned transaction inclusion rules, R11 handles situations where contract data and commercial invoice data have direct number references. The executing entity reads both the contract number and invoice number appearing simultaneously in the same trade element and includes the invoice number in the transaction starting point. R12 handles situations where the commercial invoice data does not record a contract number but its attribution can still be determined. The executing entity reads the buyer and seller, goods name, and goods quantity corresponding to the invoice number. When these contents correspond to the buyer and seller, goods name, and goods quantity in the transaction starting point, the invoice number is included in the transaction starting point. R13 handles situations where one contract corresponds to multiple invoices. The executing entity includes the goods quantity corresponding to each invoice number as part of the goods quantity under the contract and uses that invoice number as the sub-item invoice number in the transaction starting point. R14 excludes invoice numbers where the buyer and seller do not correspond or the goods names are different.

[0085] For example, contract number C1 corresponds to buyer and seller A and B, goods name M, and goods quantity 100. Invoice number F1 records contract number C1, goods name M, and goods quantity 60. Invoice number F2 does not record contract number C1 but records buyer and seller A and B, goods name M, and goods quantity 40. Then, the executing entity will classify F1 as the starting point of the transaction according to R11 and F2 as the starting point of the transaction according to R13, forming a transaction mainline that includes C1, F1, and F2.

[0086] S24: The executing entity will form the transaction main line by including the transaction starting point, the invoice number to which the transaction starting point is located, the buyer and seller, the name of the goods and the quantity of the goods.

[0087] The above process first determines the transaction lead because contract data and commercial invoice data are usually used to determine the ownership of a transaction. The transaction lead can provide a basic range for subsequent searches of bill of lading numbers, container numbers, declaration numbers, and payment numbers.

[0088] S30: Locate the bill of lading number and container number along the main transaction line, and generate the main transportation line based on the carrier relationship between the bill of lading number, container number, port of loading and port of destination.

[0089] The transport mainline refers to a data chain that, based on the name and quantity of goods, the buyer and seller, and the invoice number in the transaction mainline, groups the bill of lading number, container number, carrier, port of loading, and port of destination into the same transport scope. The carrier relationship means that the bill of lading number and container number are recorded together, and the port of loading, port of destination, and carrier corresponding to the container number represent the same cargo transport process.

[0090] like Figure 3 As shown, S30 includes S31 to S35.

[0091] S31: The executing entity reads the name of the goods, the quantity of the goods, the buyer and seller, and the invoice number along the main transaction line.

[0092] S32: The executing entity searches for the bill of lading number that appears in the set of trade elements along with the invoice number, goods name, or the buyer and seller entities. The "OR" search method is used here because some bill of lading data does not record the invoice number but will record the goods name, shipper, consignee, or the entity corresponding to the buyer and seller entities.

[0093] S33: The executing entity searches for the corresponding container number, carrier, port of loading, and port of destination in the trade element set based on the bill of lading number.

[0094] S34: When the same bill of lading number corresponds to multiple container numbers, the executing entity shall form a container transport segment according to the cargo name and quantity recorded in the container number. A container transport segment refers to a transport data segment formed by individual container numbers under the same bill of lading number. Each container transport segment includes the bill of lading number, container number, cargo name, cargo quantity, carrier, port of loading, port of destination, loading time, and arrival time. The loading time and arrival time are derived from the business occurrence time corresponding to the port operation data.

[0095] S35: The executing entity generates the main transport route based on the bill of lading number, container number, carrier, port of loading, port of destination, and sub-container transport segment.

[0096] In one example, the main transport line corresponds to cargo name M and cargo quantity 100, and bill of lading number L1 corresponds to container numbers X1 and X2. Container number X1 records cargo name M and cargo quantity 60, and container number X2 records cargo name M and cargo quantity 40. The executing entity will form X1 into the first sub-container transport segment and X2 into the second sub-container transport segment, and will include both the first and second sub-container transport segments into the main transport line. In this way, the main transport line not only records bill of lading number L1, but also records the attribution relationship between different container numbers and cargo quantities under L1.

[0097] S30 shifts the transaction mainline to the transportation mainline because goods under the same transaction may be split into multiple container numbers for transportation. If only the bill of lading number is used to merge the data, it is impossible to express the correspondence between the container number and the quantity of goods.

[0098] S40: Locate the declaration number and inspection and quarantine number along the main transportation route, and generate the main supervision route based on the batch correspondence between the cargo name, cargo quantity and container number.

[0099] The regulatory mainline refers to a data chain that groups declaration numbers and inspection and quarantine numbers under the same regulatory scope based on the bill of lading number, container number, cargo name, and cargo quantity in the main transportation line. Batch correspondence means that when the same container number corresponds to one or more declaration numbers, the cargo name and quantity recorded in each declaration number correspond completely or partially with the cargo name and quantity in that container number.

[0100] like Figure 4 As shown, S40 includes S41 to S45.

[0101] S41: The executing entity reads the bill of lading number, container number, cargo name, and cargo quantity along the main transportation route.

[0102] S42: The executing entity searches for the declaration number that appears together with the bill of lading number or container number in the set of trade elements.

[0103] S43: The implementing entity shall, based on the declaration number, search for the corresponding inspection and quarantine number and inspection and quarantine time in the set of trade elements.

[0104] S44: When multiple declaration numbers correspond to the same container number, the implementing entity shall divide the container number into multiple declaration segments according to the cargo name and cargo quantity. A declaration segment refers to a segment of regulatory data formed by declaration number under the same container number. Each declaration segment includes the container number, declaration number, inspection and quarantine number, inspection and quarantine time, cargo name, and cargo quantity.

[0105] S45: The implementing entity combines the declaration number, inspection and quarantine number, inspection and quarantine time, and declaration segment to generate the regulatory main line.

[0106] In one example, container number X1 in the transport mainline records cargo name M and cargo quantity 60. The trade element set contains declaration numbers D1 and D2. Declaration number D1 corresponds to container number X1, cargo name M, and cargo quantity 30, and declaration number D2 also corresponds to container number X1, cargo name M, and cargo quantity 30. The implementing entity forms the first declaration segment with declaration number D1 and the second declaration segment with declaration number D2, and then includes both the first and second declaration segments in the regulatory mainline. In this way, the regulatory mainline can represent batch declarations under the same container number.

[0107] S40 shifts the main line of transportation to the main line of supervision because the transportation process typically organizes data using bill of lading numbers and container numbers, while the supervision process typically organizes data using declaration numbers and inspection and quarantine numbers. The two need to establish a batch correspondence through container numbers, cargo names, and cargo quantities.

[0108] S50: Based on the buyer and seller entities, goods names, goods quantities, and transaction times that are interconnected in the transaction mainline, transportation mainline, and regulatory mainline, the payment number is assigned to the settlement mainline to generate trade event fragments.

[0109] The settlement mainline refers to the data chain that categorizes payment numbers into the trade transactions indicated by the transaction mainline, transportation mainline, and regulatory mainline. Mutual continuity means that the quantities of goods in the transaction mainline, transportation mainline, regulatory mainline, and the quantity of goods corresponding to the payment number can form a complete or partial correspondence under the same goods transaction, and the timing of the transactions conforms to the order of transaction, transportation, regulation, and settlement.

[0110] Full correspondence means that the quantity of goods read in the later main line is equal to the quantity of goods read in the earlier main line. Partial correspondence means that the quantity of a single item read in the later main line is less than the quantity read in the earlier main line, and the sum of the quantities of multiple items read in the later main line is equal to the quantity read in the earlier main line, or the sum of the quantities of multiple items read in the later main line is less than the quantity read in the earlier main line but corresponds to the same item name and the same container number. When comparing the quantity of goods, the executing entity uses the same unit of measurement recorded in the trade element set; when the units of measurement recorded in different data sources are inconsistent, the executing entity uses the unit of measurement recorded in the customs declaration data as the unit of measurement for expressing the quantity of goods, and converts the quantity of goods from other sources to that unit of measurement before comparison.

[0111] For example, if the main transaction line records a cargo quantity of 100, and the two sub-container transport segments in the main transport line record cargo quantities of 60 and 40 respectively, then the two sub-container transport segments partially correspond to the main transaction line. Similarly, if the main regulatory line forms two declaration segments for container number X1, each recording cargo quantities of 30, then these two declaration segments partially correspond to the sub-container transport segment corresponding to container number X1. If the two payment numbers in the main settlement line correspond to cargo quantities of 60 and 40 respectively, then these two payment numbers partially correspond to the main transaction line; if a payment number corresponds to a cargo quantity of 100, then that payment number fully corresponds to the main transaction line.

[0112] like Figure 5 As shown, S50 includes S51 to S55.

[0113] S51: The executing entity reads the buyer and seller, goods name, goods quantity and contract number from the transaction mainline.

[0114] S52: The executing entity reads the bill of lading number, container number, port of loading, port of destination, and carrier from the main transport line.

[0115] S53: The implementing entity reads the declaration number, inspection and quarantine number, and declaration segment from the main regulatory line.

[0116] S54: The executing entity searches for the payment number in the set of trade elements that records the buyer and seller and corresponds to the name or quantity of goods. The payment number corresponding to the name or quantity of goods means that the cross-border payment data directly records the name or quantity of goods, or that the contract number or invoice number recorded in the cross-border payment data corresponds to the contract number or invoice number in the main transaction, allowing the payment number to indirectly correspond to the name or quantity of goods.

[0117] In one example, the transaction masterline records the buyer and seller entities A and B, the goods name M, and the goods quantity 100. The cross-border payment data contains payment numbers P1 and P2. Payment number P1 records the payer A, the payee B, and the goods quantity 60; payment number P2 records the payer A, the payee B, and the goods quantity 40. The executing entity identifies payer A and payee B as the corresponding buyer and seller entities and, based on the partial correspondence between the goods quantities 60 and 40 and the goods quantity 100 in the transaction masterline, assigns payment numbers P1 and P2 to the settlement masterline. If the cross-border payment data only records payment number P3, contract number C1, and payer A, the executing entity assigns payment number P3 to the settlement masterline based on the consistency between contract number C1 and the contract number in the transaction masterline.

[0118] S55: The executing entity combines the transaction thread, transportation thread, regulatory thread, and associated payment number into a trade event fragment according to the time of the transaction. A trade event fragment refers to the collection of transaction content, transportation content, regulatory content, and settlement content under the same trade matter.

[0119] The S50 needs to be processed after the regulatory mainline because cross-border payment data may not directly record the bill of lading number or declaration number. The executing entity needs to use the buyer and seller, goods name, goods quantity and transaction time already identified in the transaction mainline, transport mainline and regulatory mainline to determine the scope of the payment number.

[0120] In one implementation, the executing entity connects the main transportation line with the main regulatory line according to the connection rules between the containerized transport segment and the declaration segment. Specifically, when the containerized transport segment and the declaration segment have the same container number, the executing entity first assigns the container number; under the same container number, the executing entity then assigns it according to the cargo name; when the same cargo name corresponds to multiple declaration numbers, the executing entity assigns it according to the full or partial correspondence of the cargo quantity. This connection rule provides a clear data transfer process between the containerized transport segment and the declaration segment.

[0121] S60: Based on the initial data source and business occurrence time corresponding to each trade element in the trade event segment, divide the event into goods delivery event, document circulation event, regulatory handling event, and fund settlement event.

[0122] like Figure 6As shown, S60 includes S61 to S64.

[0123] S61: The implementing entity classifies trade elements derived from contract data and commercial invoice data in a trade event fragment into a document flow event.

[0124] S62: The executing entity classifies trade elements derived from bill of lading data and port operation data in a trade event fragment into a goods delivery event.

[0125] S63: The implementing body will classify trade elements derived from customs declaration data and inspection and quarantine data in trade event fragments into regulatory handling events.

[0126] S64: The implementing entity classifies trade elements derived from cross-border payment data in trade event fragments into fund settlement events.

[0127] S60 is executed after the trade event fragments are formed because at this time, all trade elements have been classified into the same trade event. Dividing the events according to the initial data source can prevent different trade events from being classified into the same event simply because they have the same data source.

[0128] S70: Generate integrated data records based on the chronological order of goods delivery events, document circulation events, regulatory disposal events, and fund settlement events.

[0129] Integrated data recording refers to the recording of document transfer events, goods delivery events, regulatory handling events, and fund settlement events under the same trade transaction, while retaining the chronological order of these events. This chronological order is not simply determined by time sequence, but rather by a combination of number references, location relationships, regulatory numbers, and payment numbers.

[0130] like Figure 7 As shown, S70 includes S71 to S75.

[0131] S71: The executing entity extracts the contract number, invoice number, and business occurrence time from the document circulation event, places the trade element that records the contract number before the trade element that records the invoice number, and arranges multiple invoice numbers that record the same contract number according to the business occurrence time to determine the document reference order.

[0132] S72: The executing entity extracts the bill of lading number, container number, port of loading, port of destination, and time of business occurrence from the goods delivery event, places the time of business occurrence of the corresponding port of loading before the time of business occurrence of the corresponding port of destination, and arranges multiple container numbers that share the same bill of lading number according to the time of business occurrence to determine the order of goods carriage.

[0133] S73: The implementing entity extracts the declaration number, inspection and quarantine number, and business occurrence time from the regulatory and disposal events, places the trade elements that record the declaration number before the trade elements that record the inspection and quarantine number, and arranges multiple inspection and quarantine numbers that record the same declaration number according to the business occurrence time to determine the order of regulatory and disposal.

[0134] S74: In the fund settlement event, the payment number, buyer and seller, goods name, goods quantity, and transaction time will be used to arrange multiple payment numbers that correspond to the same buyer and seller, the same goods name, or the same goods quantity according to the transaction time to determine the order of settlement.

[0135] S75: The executing entity connects document circulation events, goods delivery events, regulatory disposal events, and fund settlement events according to the order of document citation, goods transportation, regulatory disposal, and settlement, and generates integrated data records.

[0136] In S70 above, the time of business occurrence is used to arrange multiple trade elements within the same type of event; number references and business relationships are used to determine the order of succession between different types of events. Therefore, the merged data record can express the attribution relationships between contract numbers, invoice numbers, bills of lading numbers, container numbers, declaration numbers, inspection and quarantine numbers, and payment numbers under the same trade transaction.

[0137] In one example, the merged data record includes transaction record items, transportation record items, regulatory record items, and settlement record items. The transaction record item records contract number C1 and invoice numbers F1 and F2; the transportation record item records bill of lading number L1 and container numbers X1 and X2; the regulatory record item records declaration numbers D1 and D2 corresponding to container number X1, and declaration number D3 corresponding to container number X2; the settlement record item records payment numbers P1 and P2. The merged data record also records that F1 and F2 belong to C1, X1 and X2 belong to L1, D1 and D2 belong to X1, D3 belongs to X2, and P1 and P2 belong to C1. Through this record structure, the executing entity can maintain the attribution relationships between documents, transportation, regulation, and settlement.

[0138] In one implementation, the executing entity may perform transaction incorporation, transportation incorporation, regulatory incorporation, and settlement incorporation according to the following rules.

[0139] R21 Trading Mainline Contract number and invoice number appear together Incorporate invoice numbers into the main transaction line. R22 Trading Mainline The invoice number does not record the contract number, but the buyer and seller correspond, the goods names are the same, and the quantity of goods corresponds fully or partially to the contract number. Invoice numbers are incorporated into the main transaction line. R31 Main transport line Bill of lading number and invoice number appear together The bill of lading number will be assigned to the main transportation route. R32 Main transport line The bill of lading number does not include the invoice number, but the goods name or the buyer / seller corresponding to the bill of lading number is consistent with the main transaction. The bill of lading number will be assigned to the main transportation route. R41 Regulatory main line The declaration number appears together with the bill of lading number or container number. Incorporate application numbers into the regulatory framework. R42 Regulatory main line Multiple declaration numbers corresponding to the same container number Multiple declaration segments are formed based on the name and quantity of goods. R51 Settlement Mainline The payment number records the buyer and seller and corresponds to the name or quantity of goods. Incorporate payment numbers into the settlement mainline. R52 Settlement Mainline Multiple payment numbers correspond to the same buyer and seller, and are associated with the same goods name or quantity. Multiple payment codes are grouped into the settlement mainline based on the time of the transaction.

[0140] In the rule table above, R21 and R22 correspond to the formation process of the transaction mainline, used to determine whether the invoice number falls within the transaction scope corresponding to the contract number. R31 and R32 correspond to the formation process of the transportation mainline, used to determine whether the bill of lading number falls within the transportation scope corresponding to the transaction mainline. R41 and R42 correspond to the formation process of the regulatory mainline, used to determine whether the declaration number falls within the regulatory scope corresponding to the transportation mainline, and to form a declaration segment when multiple declaration numbers correspond to the same container number. R51 and R52 correspond to the formation process of the settlement mainline, used to determine whether the payment number falls within the trade matter jointly pointed to by the transaction mainline, transportation mainline, and regulatory mainline. When the implementing entity executes the above rules, it processes them sequentially according to the order of transaction mainline, transportation mainline, regulatory mainline, and settlement mainline, using the result of the previous mainline as the search scope or attribution basis for the generation of the later mainline.

[0141] The aforementioned rule table describes a specific execution method for the numbering reference relationships, carrier relationships, batch correspondence relationships, and mutual succession relationships in S20 to S50. The executing entity reads the trade elements in the trade element set item by item according to the rule table and writes the reading results into the corresponding main line.

[0142] This embodiment does not use a model that requires training, nor does it use formulas involving unit conversion. The quantity of goods is only used to determine whether there is a full or partial correspondence for the same goods item. For quantities of goods in different units of measurement, the executing entity first uses the unit of measurement recorded in the customs declaration data as the unit of expression for the quantity of goods, and then compares the quantities. Therefore, this embodiment does not involve the direct comparison of quantities of goods in different units of measurement.

[0143] This embodiment also provides a data fusion system for multi-source heterogeneous trade data. For example... Figure 8 As shown, the data fusion system 100 includes an extraction module 110, a first generation module 120, a second generation module 130, a third generation module 140, a fourth generation module 150, a division module 160, and a fifth generation module 170.

[0144] The extraction module 110 is used to execute S10, obtain an initial data set, and extract trade elements from the initial data set to generate a trade element set.

[0145] The first generation module 120 is used to execute S20, which generates the transaction main line based on the contract number, invoice number, and the reference relationship between the buyer and seller.

[0146] The second generation module 130 is used to execute S30, which searches for the bill of lading number and container number along the main transaction line, and generates the main transportation line based on the carrier relationship between the bill of lading number, container number, port of loading and port of destination.

[0147] The third generation module 140 is used to execute S40, which searches for the declaration number and inspection and quarantine number along the main transportation line, and generates the regulatory main line based on the batch correspondence between the cargo name, cargo quantity and container number.

[0148] The fourth generation module 150 is used to execute S50, which, based on the buyer and seller entities, goods names, goods quantities and business occurrence times that are interconnected in the transaction main line, transportation main line and regulatory main line, assigns the payment number to the settlement main line and generates trade event fragments.

[0149] The segmentation module 160 is used to execute S60, which divides the trade event into goods delivery events, document circulation events, regulatory disposal events, and fund settlement events according to the initial data source and business occurrence time of each trade element in the trade event segment.

[0150] The fifth generation module 170 is used to execute S70, which generates fused data records based on the sequence of goods delivery events, document circulation events, regulatory disposal events, and fund settlement events.

[0151] This embodiment also provides a computing device. The computing device includes a processing component and a storage component. The storage component stores one or more computer instructions, which are invoked and executed by the processing component to implement the above-described data fusion method for multi-source heterogeneous trade data.

[0152] This embodiment also provides a computer storage medium. The computer storage medium stores a computer program, which, when executed by a computer, implements the above-described data fusion method for multi-source heterogeneous trade data.

[0153] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A data fusion method for multi-source heterogeneous trade data, characterized in that, include: An initial data set is obtained, and trade elements are extracted from the initial data set to generate a trade element set. The initial data set includes customs declaration data, bill of lading data, commercial invoice data, contract data, inspection and quarantine data, port operation data, and cross-border payment data. The trade elements include the name of the goods, the quantity of the goods, the buyer and seller, the carrier, the port of loading, the port of destination, the container number, the contract number, the invoice number, the bill of lading number, the declaration number, the inspection and quarantine number, the inspection and quarantine time, the payment number, and the time of the transaction. A transaction thread is generated based on the contract number, the invoice number, and the reference relationships between the buyer and seller. The bill of lading number and container number are located along the main transaction line, and the transportation main line is generated based on the bill of lading number, the container number, the carrier relationship between the port of loading and the port of destination; The declaration number and inspection and quarantine number are located along the main transportation route, and a supervision route is generated based on the batch correspondence between the cargo name, cargo quantity and the container number; Based on the buyer and seller entities, goods names, goods quantities, and business occurrence times that are interconnected in the transaction main line, the transportation main line, and the regulatory main line, the payment number is assigned to the settlement main line to generate a trade event fragment; Based on the initial data source and business occurrence time corresponding to each trade element in the aforementioned trade event segment, the events are divided into goods delivery events, document circulation events, regulatory handling events, and fund settlement events. Based on the chronological order of the goods delivery event, the document transfer event, the regulatory action event, and the fund settlement event, a fused data record is generated.

2. The method according to claim 1, characterized in that, Based on the contract number, the invoice number, and the reference relationships between the buyer and seller, a transaction thread is generated, including: Select a contract number from the set of trade elements as the starting point of the transaction; Find the invoice number, buyer and seller, goods name, and goods quantity that appear together with the contract number in the set of trade elements; When the invoice number does not record the contract number, the corresponding invoice number is assigned to the transaction starting point based on the same buyer and seller, goods name, goods quantity, and transaction time to generate the transaction main line.

3. The method according to claim 1, characterized in that, The process involves tracing the bill of lading number and container number along the main transaction route, and generating a transportation main route based on the bill of lading number, the container number, and the carrier relationship between the port of loading and the port of destination, including: Read the goods name, quantity, buyer and seller, and invoice number along the main transaction line; Search within the set of trade elements for the bill of lading number that appears together with the invoice number, the goods name, and the buyer and seller entities; Based on the bill of lading number, the corresponding container number, carrier, port of loading, and port of destination can be found in the set of trade elements. When the same bill of lading number corresponds to multiple container numbers, container transport segments are formed according to the cargo name and quantity recorded in the container number; Based on the bill of lading number and the container number, the loading time and arrival time are determined from the port operation data; The bill of lading number, container number, port of loading, port of destination, loading time, and arrival time are combined to generate the main transportation route.

4. The method according to claim 1, characterized in that, The declaration number and inspection and quarantine number are located along the main transportation route, and a regulatory main line is generated based on the batch correspondence between the cargo name, cargo quantity, and container number, including: Read the bill of lading number, container number, cargo name, and cargo quantity along the main transportation route; Search the set of trade elements for the declaration number that appears together with the bill of lading number or the container number; Based on the declaration number, find the corresponding inspection and quarantine number and inspection and quarantine time in the set of trade elements; When the same container number corresponds to multiple declaration numbers, the container number shall be split into multiple declaration segments according to the cargo name and cargo quantity; The regulatory mainline is generated by combining the application number, the application time, the inspection and quarantine number, and the application segment.

5. The method according to claim 1, characterized in that, Based on the buyer and seller entities, goods names, goods quantities, and transaction times that are interconnected within the transaction mainline, the transportation mainline, and the regulatory mainline, the payment number is assigned to the settlement mainline to generate a trade event fragment, including: Read the buyer and seller entities, goods name, goods quantity, and contract number from the transaction mainline; Read the bill of lading number, container number, port of loading, port of destination, and carrier from the main transportation route; Read the declaration number and inspection and quarantine number from the aforementioned regulatory framework; Search the set of trade elements for the payment number that records the buyer and seller and corresponds to the name or quantity of goods. The transaction mainline, the transportation mainline, the regulatory mainline, and the assigned payment number are combined into trade event fragments according to the time of the business occurrence.

6. The method according to claim 1, characterized in that, Based on the initial data source and business occurrence time corresponding to each trade element in the aforementioned trade event segment, the events are divided into goods delivery events, document circulation events, regulatory handling events, and fund settlement events, including: Trade elements derived from contract data and commercial invoice data in the aforementioned trade event fragments are categorized into the document circulation event; The trade elements derived from bill of lading data and port operation data in the aforementioned trade event fragments are classified into the cargo delivery event; Trade elements derived from customs declaration data and inspection and quarantine data in the aforementioned trade event fragments are classified into the aforementioned regulatory handling events; Trade elements derived from cross-border payment data in the aforementioned trade event fragments are categorized into the aforementioned fund settlement events.

7. The method according to claim 1, characterized in that, Based on the chronological order of the goods delivery event, the document transfer event, the regulatory handling event, and the fund settlement event, a fused data record is generated, including: Extract the contract number, invoice number, and business occurrence time from the document circulation event. Place the trade element that records the contract number before the trade element that records the invoice number, and arrange multiple invoice numbers that record the same contract number according to the business occurrence time to determine the document reference order. Extract the bill of lading number, container number, port of loading, port of destination, and transaction time from the cargo delivery event. Place the transaction time of the corresponding port of loading before the transaction time of the corresponding port of destination. Arrange multiple container numbers that share the same bill of lading number according to the transaction time to determine the cargo carrying order. Extract the declaration number, inspection and quarantine number, and business occurrence time from the aforementioned regulatory handling event. Place the trade element that records the declaration number before the trade element that records the inspection and quarantine number, and arrange multiple inspection and quarantine numbers that record the same declaration number according to the business occurrence time to determine the order of regulatory handling. Extract the payment number, buyer and seller, goods name, goods quantity, and transaction time from the fund settlement event. Arrange multiple payment numbers that correspond to the same buyer and seller, the same goods name, and the same goods quantity according to the transaction time to determine the settlement order. The fused data record is generated by connecting the document transfer event, the goods delivery event, the regulatory disposal event, and the fund settlement event according to the document reference order, the goods shipment order, the regulatory disposal event, and the fund settlement event.

8. A data fusion system for multi-source heterogeneous trade data, characterized in that, A system for implementing the data fusion method for multi-source heterogeneous trade data as described in any one of claims 1-7; the system comprises: The extraction module is used to obtain an initial data set and extract trade elements from the initial data set to generate a trade element set. The initial data set includes customs declaration data, bill of lading data, commercial invoice data, contract data, inspection and quarantine data, port operation data, and cross-border payment data. The trade elements include goods name, goods quantity, buyer and seller, carrier, port of loading, port of destination, container number, contract number, invoice number, bill of lading number, declaration number, inspection and quarantine number, inspection and quarantine time, payment number, and transaction occurrence time. The first generation module is used to generate a transaction mainline based on the contract number, the invoice number, and the reference relationship between the buyer and seller. The second generation module is used to find the bill of lading number and container number along the main transaction line, and generate the main transportation line based on the bill of lading number, the container number, the carrier relationship between the port of loading and the port of destination; The third generation module is used to search for the declaration number and inspection and quarantine number along the main transportation line, and generate the supervision line according to the batch correspondence between the cargo name, cargo quantity and the container number; The fourth generation module is used to assign the payment number to the settlement line and generate trade event fragments based on the buyer and seller entities, goods names, goods quantities and business occurrence times that are interconnected in the transaction line, the transportation line and the regulatory line. The segmentation module is used to segment goods delivery events, document circulation events, regulatory handling events, and fund settlement events according to the initial data source and business occurrence time of each trade element in the trade event segment. The fifth generation module is used to generate fused data records based on the chronological relationship between the goods delivery event, the document circulation event, the regulatory disposal event, and the fund settlement event.

9. A computing device, characterized in that, It includes a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are invoked and executed by the processing component to implement a data fusion method for multi-source heterogeneous trade data as described in any one of claims 1-7.

10. A computer storage medium, characterized in that, The system contains a computer program that, when executed by a computer, implements a data fusion method for multi-source heterogeneous trade data as described in any one of claims 1-7.

Images