CN111353841B

CN111353841B - Document data processing method, device and system

Info

Publication number: CN111353841B
Application number: CN201811575016.XA
Authority: CN
Inventors: 黄锴
Original assignee: Hema China Co Ltd
Current assignee: Hema China Co Ltd
Priority date: 2018-12-21
Filing date: 2018-12-21
Publication date: 2023-07-25
Anticipated expiration: 2038-12-21
Also published as: CN111353841A

Abstract

The embodiment of the application discloses a bill data processing method, a bill data processing device and a bill data processing system, wherein the bill data processing system comprises the following steps: the second system is used for processing commodity object data on the target node in the link, generating bill data and providing the bill data for the first system through the communication channel; the first system is used for obtaining node identification information, upstream and downstream relation information between nodes and bill data matching rule information between nodes, which are included in the links, generating a checking task after receiving the bill data provided by the second system, and checking the bill data on the nodes in the links aiming at the checking task. Through the embodiment of the application, document data verification can be realized when the distributed architecture and the plurality of business applications work cooperatively.

Description

Document data processing method, device and system

Technical Field

The present disclosure relates to the field of document data processing technologies, and in particular, to a document data processing method, device, and system.

Background

In a merchandise object sales system, financial data reconciliation is one of the more important. Taking the transaction link with the largest data volume as an example, in the conventional data checking scheme, the problem of checking the data of the traditional store is mainly solved. In this scenario, the user takes away the goods after the cash register completes the payment, and the transaction can be completed immediately, and the transaction payment and the commodity delivery can be considered to be completed at the same time, and the transaction link is simple. In addition, the scene transaction amount is small, the system is generally deployed in a centralized way, all data are stored in the same database, all services are in the same database and are synchronously completed, so that the data consistency is ensured to be checked through database transactions.

However, in a mode of combining online and offline such as "new retail", retailers may provide information of merchandise objects through online application programs (apps) provided by the "new retail" platform, and users may conduct browsing, purchasing, etc. through the online apps. Meanwhile, retailers can also open off-line physical shops, and users can purchase commodity objects through the off-line physical shops. The online order may be shipped from an offline physical store and the like, and finally delivered to a user-designated shipping address. Some off-line physical shops also need to carry out various treatments such as warehousing, goods adjustment, goods replenishment and the like. In the above-mentioned transaction, warehouse entry, goods adjustment, goods replenishment, etc., a long processing link is generally involved.

Taking a transaction scene as an example, in a 'new retail' mode, the method has the characteristics that the transaction order quantity is large, online and offline are integrated, a small amount of transactions occur in a store, and most of transactions are online and offline of users. For the case of online ordering, a specific commodity needs to be sent to the hand of a user by a dispatcher, and the whole transaction link is calculated and completed only after the user signs the commodity. Transaction payment and commodity delivery are thus completed asynchronously, typically separated by a period of time ranging from 1 hour to several days. Moreover, the entire transaction link may be completed by a plurality of different business departments and even different application systems, for example, an application used in a transaction process and an application used in a distribution process may be independent from each other, and these data may be distributed in databases of business servers of different application systems, so that data consistency cannot be ensured directly through database transactions.

Therefore, how to effectively verify document data under a complex link becomes a technical problem that needs to be solved by those skilled in the art.

Disclosure of Invention

The document data processing method, device and system can realize document data verification in the process of cooperative work of a distributed architecture and a plurality of service applications, avoid influencing the data processing flow on specific service nodes, avoid the condition that document data is tampered by one service node, and the like, and ensure the accuracy and the effectiveness of verification results.

The application provides the following scheme:

a document data processing system, comprising:

the first system and a plurality of second systems, the second systems correspond to nodes in the commodity object data processing link; wherein a communication channel is arranged between the first system and the second system;

the second system is used for processing commodity object data on a target node in the link to generate bill data, and the bill data is provided for the first system through the communication channel;

the first system is configured to obtain node identification information, upstream and downstream relationship information between nodes, and document data matching rule information between nodes included in the link, and generate a verification task after receiving document data provided by the second system, and perform verification on the document data on the nodes in the link with respect to the verification task.

A document data processing method, comprising:

acquiring node identification information, upstream and downstream relation information between nodes and document data matching rule information corresponding to the nodes, wherein the node identification information is included in a commodity object data processing link;

generating a checking task after receiving bill data provided by a plurality of second systems; wherein the second system corresponds to a node in the commodity object data processing link;

and checking the bill data on the nodes in the link aiming at the checking task.

A document data processing method, comprising:

processing commodity object data on a target node in a commodity object data processing link and generating bill data;

and providing the bill data to a first system so that the first system generates a checking task, and checking the bill data on the nodes in the link according to the pre-stored upstream and downstream relation information between the nodes and the matching rule by taking the checking task as a unit.

A document data processing apparatus comprising:

the information obtaining unit is used for obtaining node identification information, upstream and downstream relation information between nodes and bill data matching rule information corresponding to the nodes, wherein the node identification information, the upstream and downstream relation information and the bill data matching rule information are included in the commodity object data processing link;

The checking task generating unit is used for generating a checking task after receiving the bill data provided by the second systems; wherein the second system corresponds to a node in the commodity object data processing link;

and the checking unit is used for checking the bill data on the nodes in the link aiming at the checking task.

A document data processing apparatus comprising:

the bill data generating unit is used for processing commodity object data on a target node in the commodity object data processing link and generating bill data;

and the bill data providing unit is used for providing the bill data for the first system so that the first system generates a checking task, and checking the bill data on the nodes in the link according to the upstream and downstream relation information among the nodes and the matching rule which are stored in advance by taking the checking task as a unit.

An electronic device, comprising:

one or more processors; and

a memory associated with the one or more processors, the memory for storing program instructions that, when read for execution by the one or more processors, perform the operations of:

According to a specific embodiment provided by the application, the application discloses the following technical effects:

in the embodiment of the application, by providing the first system independent of the second system where the service processing node in the specific link is located, and establishing a communication channel between the first system and the second system, bill data generated in the second system can be provided to the first system through the communication channel, and bill data generated in the second system where different nodes on the same link are located can be checked in the first system. By the method, document data checking in the cooperative work of the distributed architecture and the plurality of business applications can be realized, the document data checking problem of a plurality of business links, a plurality of business servers and a complex link is solved, and the data processing flow on a specific business node is not influenced. In addition, since the bill data in the second system can be sent to the first system, the subsequent specific checking process is transparent for the second system, so that the condition that the bill data is tampered by a certain service node can be avoided, and the accuracy and the effectiveness of the checking result are ensured.

In the checking process, starting from the initial node of the link, checking the bill data on the nodes in the link in sequence according to the upstream and downstream relation information among the nodes in the link and a preset matching rule.

In addition, if a certain link in the link is not successfully checked, the checking task can be continuously retried, and the task timing retrying mechanism can solve the difficult problem of long-time checking between transaction payment and commodity delivery. Moreover, by the task retry mechanism, the task state can be set to be successful after all node checks on each link are completed, and the condition that any income is not missed is ensured.

Of course, not all of the above-described advantages need be achieved at the same time in practicing any one of the products of the present application.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are needed in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a system provided by an embodiment of the present application;

FIG. 2 is a schematic diagram of a process flow provided in an embodiment of the present application;

FIG. 3 is a schematic diagram of a collation sequence provided by an embodiment of the present application;

FIG. 4 is a flow chart of a first method provided by an embodiment of the present application;

FIG. 5 is a flow chart of a second method provided by an embodiment of the present application;

FIG. 6 is a schematic diagram of a first apparatus provided in an embodiment of the present application;

FIG. 7 is a schematic diagram of a second apparatus provided in an embodiment of the present application;

fig. 8 is a schematic diagram of an electronic device provided in an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present application are within the scope of the protection of the present application.

In the embodiment of the present application, in order to enable verification of relevant document data in a complex link scenario, a verification server is provided (of course, there may be other names, which are collectively referred to as "first system" in the embodiment of the present application). The first system may be independent of the particular business system server. Of course, the independence in the embodiments of the present application may specifically refer to functional independence, and may specifically be separately deployed on one or more dedicated physical devices. Or may be deployed in a server of one of the service systems, but logically needs to be isolated from the specific service processing logic; still alternatively, in the embodiment of the present application, the verification result provided by the first system may be mainly provided to relevant systems such as finance, so that a specific first system may also be directly deployed on one or more physical devices in the finance system, and so on.

In this embodiment of the present application, the processing operations on different service nodes in the same link may be distributed on servers of different service systems (that is, servers corresponding to each specific node on the specific commodity object information processing link respectively, which may be referred to as a second system in this embodiment of the present application), and even be completed through different applications. For this reason, in the embodiment of the present application, the second system on each specific service node may also provide the specifically generated document data to the first system, and then the first system performs a unified verification process.

In order to achieve the above object, a communication connection can be established between the first system and the second system, so that information can be communicated with each other. For example, in a specific implementation, a message communication mechanism may be used, so that the second system may generate a specific message packet according to a certain format, and the first system may receive the message packet of the second system through a message listening mechanism, and may identify a message in the message, or the like.

The specific bill data is mainly used for checking data related to finance and the like, so that specific condition information can be stored in the second system, the second system can be matched with the condition information after the specific bill data is generated, and if the state of the bill data accords with the condition information, a corresponding message packet can be generated and sent to the first system. For example, specific conditions may be that document data needs to be sent once generated, or that processing operations on specific nodes are sent once completed, and so on. That is, the status of the document data in the second system may be automatically transmitted to the first system by means of a message once a predetermined condition related to the financial verification is satisfied. And then, checking specific bill data on the first system, wherein the first system and the second system are mutually independent, so that on one hand, the influence on the data processing flow on specific service nodes can be avoided, and on the other hand, the condition that the bill data is tampered by one of the service nodes and the like can be avoided, and the accuracy and the effectiveness of a checking result are ensured.

In order to perform specific checking operation, node identification information, upstream and downstream relationship information between nodes and document data matching rule information corresponding to the nodes, which are included in a specific commodity object data processing link, may be stored in the first system in advance. For example, for a transaction link, specifically included nodes may be transactions, performances, inventory, delivery, etc., where a "transaction" is the starting node of the link, the first node downstream of which is "performances", the next node is "inventory", the next node is "delivery", etc. In addition, in particular, when checking document data related to finance and the like, it is common to check document data generated at different nodes. For example, after a consumer completes one order on line, a corresponding transaction receipt is generated in a transaction link, then the transaction receipt is processed in a performance link, a corresponding performance receipt is generated, after the performance is completed, the transaction receipt is processed in an inventory link, a corresponding inventory receipt is generated, and the like. In checking bill data, the method mainly aims at the transaction bill which is specifically generated, and judges whether the bill data which is generated for the transaction bill in each subsequent link is accurate, complete and consistent, whether the bill data is completed on time or not, and the like.

After receiving specific bill data, the first system can generate a checking task according to the bill data provided by the second system corresponding to the initial node in the specific link, and then check the bill data on the node in the link according to the checking task. In a preferred implementation manner, in the process of executing a specific checking task, the starting node can start to check bill data on each link at the upstream and downstream of the link in sequence, one service link is successfully matched, then the next service link can be checked, the former link is not successfully checked, and the checking task can be put into a retry queue to wait for the next task scheduling, and the like.

By the method, when the distributed architecture and the plurality of service applications work cooperatively, document data are checked, the problem of document data checking related to a plurality of service links, a plurality of service servers and complex links is solved, the data processing flow on a specific service node is not influenced, the condition that the document data are tampered by one of the service nodes and the like can be avoided, and the accuracy and the effectiveness of a checking result are ensured. In addition, if a certain link in the link is not successfully checked, the checking task can be continuously retried, and the task timing retrying mechanism can solve the difficult problem of long-time checking between transaction payment and commodity delivery. Moreover, by the task retry mechanism, the task state can be set to be successful after all node checks on each link are completed, and the condition that any income is not missed is ensured.

The following describes the specific technical scheme provided in the embodiment of the present application in detail.

Example 1

First, this embodiment provides a document data processing system, specifically, referring to fig. 1, the system may specifically include: a first system 101 and a plurality of second systems 102, the second systems 102 corresponding to nodes in a commodity object data processing link; wherein a communication channel is provided between the first system 101 and the second system 102;

the second system 102 is configured to process commodity object data on one node in the link, generate document data, and provide the document data to the first system through the communication channel;

the first system 101 is configured to obtain node identification information, upstream and downstream relationship information between nodes, and document data matching rule information between nodes included in the link, and generate a verification task after receiving document data provided by the second system, and perform verification on document data on nodes in the link with respect to the verification task.

The specific commodity object data processing link may have multiple numbers, for example, in a transaction scenario, may specifically refer to a transaction link, in a commodity warehouse-in scenario, may refer to a commodity warehouse-in link, and so on. In different links, a plurality of specific service nodes are typically involved, and the processing logic of these nodes is distributed over a plurality of different second systems.

In the embodiment of the present application, first node identification information, upstream-downstream relationship information between nodes, and document data matching rule information between nodes included in a commodity object data processing link may be stored in advance in a first system. For example, in one implementation, the information stored in the first system may be specifically as shown in table 1:

TABLE 1

The specific links include nodes, upstream and downstream relations among the nodes, matching rules corresponding to the nodes, and the like, and can be specifically customized by users. That is, it may be different for different users to check document data on which nodes, so, in order to meet different needs of different users, a specific custom operation entry may be provided for the users, so, the server may obtain node information included in a specific link, an upstream-downstream relationship between the nodes, and a matching rule corresponding to the nodes by receiving custom information submitted by the users.

The specific matching rule information may be determined according to the situation in the actual service scenario, and in addition, in specific implementation, the specific matching rule is not limited to be between two nodes, and some rules may need to be satisfied between multiple nodes, and so on. For example, still taking the transaction link scenario as an example, when document data on a specific performing node is matched, the corresponding matching rule may be a matching rule between the transaction node and the performing node, including whether the commodity object names, the quantity, and the like are consistent. In specific implementation, information about nodes, matching rules and the like in a specific link can be configured by writing codes, or a corresponding configuration interface can be provided, so that a user can configure by performing visual configuration in the configuration interface, and the like.

On the basis of the above information stored in the first system, the second system can provide the specifically generated document data to the first system. The second system may be a service system for providing a function implementation of one or several nodes in a specific service link, that is, in this embodiment of the present application, a link includes a plurality of nodes, where functions on the nodes are distributed in a plurality of different service systems, and a specific data processing task on a certain link needs to be completed by jointly matching a plurality of servers distributed in different systems. For example, also taking a transaction link as an example, in the case that a consumer purchases a certain commodity object through an App or the like on line, a transaction order may be first generated by a transaction system, and bill information related to finance may be generated; the information (including order number, commodity object name, quantity, etc.) in the trade order may be provided to the performance system, which may then generate corresponding performance tasks according to the information in the trade order, corresponding to the performance order, and corresponding to the performance order, may also generate performance documents related to finance. After the performing operation is completed, the specific processing flow also enters an inventory system and a distribution system to respectively generate corresponding inventory documents, distribution documents and the like. In the process of processing tasks in the node by the second system in each link, corresponding bill data is generated, and the bill data can mainly reflect data required by departments such as finance. In this embodiment of the present application, after specific document data is generated in the second system, the condition information may be set according to a preset condition information, where the condition information may include a specific document type, a corresponding state triggering condition, and so on. Thus, the second system can determine whether the state of the specific document data satisfies specific conditions, and if so, can provide the state to the first system. The preset condition information may be set according to specific conditions of data required in a related system such as finance. For example, for a "performance" link, when a certain performance unit changes to a "completed" state, corresponding performance document data may be provided to the first system, and so on.

That is, the second system generates corresponding bill data in the process of processing the data generated in the actual service scene on the service node where the second system is specifically located, and once the data meets the preset condition, the data can be provided to the first system, and the first system performs specific data checking operation. In other words, the first system provides the specific bill data to the first system in the bill data generation stage, and the subsequent specific checking operation is completed in the first system, so that even if the bill data on a certain node is different in the checking process, the second system corresponding to the node cannot attempt to avoid penalty by tampering with the data.

In particular, the first system may receive document data provided by the second system in a number of ways. For example, in one of the ways, the second system may actively provide specific document data to the first system, and may specifically transmit by way of messages, at which time the first system may receive by listening for messages from the respective second systems, as described above. Of course, in other manners, the request may be acquired by the first system from the second system, and so on.

In summary, the first system can acquire specific document data from the second system, where, since the second system is multiple, multiple document data are usually generated in parallel in the specific second system, so the document data received by the first system will be multiple. In addition, for the same service order (for example, a transaction order generated after a customer user line places a bill, or a replenishment bill generated after a merchant initiates replenishment, etc.), different links on the same link may have different processing times, and may be separated from each other by a relatively long time, so the same checking task may take a relatively long time to be finally completed, and during this time, more bill data may be continuously received from the second system. Therefore, the processing manner of the first system may specifically be that, after receipt of the document data of the second system, the document data may be first stored locally in the first system. In addition, each piece of bill data can carry information such as a message source, for example, from a specific second system, even can directly carry information such as a specific node identifier, and the like, so that the first system can know the node identifier corresponding to each piece of bill data. For example, in a specific implementation, the information of the document data received by the first system may be as shown in table 2:

TABLE 2

Document identification	Second System identification	Node identification
			10001	2001	Transaction
10002	2001	Transaction
			10003	2002	Performance of walking
10004	2003	Inventory of
			……	……	……

That is, at the same time, the receipt data received by the first system may include a plurality of transaction receipts provided by the second system of the transaction node, a plurality of performance receipts provided by the second system of the performance node, and so on. The first system may then also generate a verification task based on the received document data and then verify the document one by one.

The specific checking task is that the first link is processed by the second system corresponding to the initial node for the same service order, and the first generated bill data corresponding to the initial node and the bill data generated in the second systems on other downstream nodes are usually generated after the initial node completes the processing of the first link. In addition, when checking is actually performed, it is mainly determined whether the bill data generated by the starting node and the matched bill data with the bill data with data consistency exist on each subsequent downstream node. Therefore, particularly when generating the pairing task, a plurality of checking tasks can be generated according to the bill data provided by the second system corresponding to the specific starting node. In particular, when the first system further stores the node identifier included in each link and the upstream-downstream relationship between the node identifiers, the first system can learn about the initial node identifier of each link, and the received document data carries a specific second system identifier or node identifier, so that in a word, the node identifier corresponding to each document data can be determined, and after receiving one document data, the first system can determine whether the document data is generated by the second system corresponding to the initial node of a certain link according to the node identifier corresponding to the first system. If so, a verification task may be generated accordingly. For example, for a transaction link, if the starting node is a transaction, document data provided by the second system corresponding to the transaction node may be extracted from the received document data, and then a plurality of verification tasks may be generated according to the document data, and so on.

Since there may be multiple specific scenarios and multiple specific link types, and the starting nodes corresponding to different link types may be different, the starting nodes corresponding to the different link types may be summarized, and then multiple checking tasks are generated for document data corresponding to the starting nodes, and meanwhile, the link type corresponding to each checking task may be determined. For example, the starting node of the transaction link is a transaction node, and the starting node of the goods-adjusting link is a goods-adjusting node, if a certain receipt data corresponds to the transaction node, a checking task can be generated according to the receipt data, the receipt data can be determined to be the receipt data generated in the transaction link, and later when checking is specifically performed, checking can be performed according to the upstream and downstream node information in the transaction link and the matching rule information. If a certain bill data corresponds to a cargo transferring node, a checking task can be generated according to the bill data, but the bill data can be determined to be the bill data generated in the cargo transferring link, and later when checking is performed specifically, checking can be performed according to upstream and downstream node information in the cargo transferring link and matching rule information.

In particular, since the number of the checking tasks is plural, and it is generally necessary to take a relatively long time to complete checking of the same checking task, the checking tasks may be added to the task queue according to information such as the time sequence. Specific checking tasks can be taken out of the queue later to check one by one. For example, in a specific implementation, the information stored in the task queue of the first system may be as shown in table 3:

TABLE 3 Table 3

Checking task identity	Document identification	Node identification	Link type
				30001	10001	Transaction	Transaction link
30002	10002	Transaction	Transaction link
				……	……	……	……

When each checking task is checked, the bill data on the nodes in the link can be checked in sequence from the starting node according to the upstream and downstream relation information and the matching rule. Specifically, in the case of multiple different link types, the nodes included in the different link types may have different upstream and downstream relationships, matching rules, and the like, so that the target link type corresponding to the matching task may be determined according to the starting node identifier in the matching task, and then the document data may be checked according to the upstream and downstream relationship information corresponding to the target link type and the matching rule information. For example, if the initial node identifier corresponding to a check task is "transaction", it may be determined that the corresponding link type is a transaction link, and further it may be determined that the second node in the link is performing, the third node is inventory, the last node is delivery, and so on. And then matching the bill data on each node in turn according to the upstream and downstream sequences.

After determining information such as a specific link type, and the like, particularly when checking, a first system can firstly take out document data corresponding to a next node from received document data aiming at a current node which has completed matching in the checking task, then, perform matching judgment on the document data corresponding to the next node by utilizing matching rule information between the current node and the next node, and if matching is successful, take the next node as a new current node and perform matching judgment on the document data corresponding to the next node of the new current node. That is, only after the document data corresponding to one node on one link is successfully matched, the data of the next node is matched.

It should be noted that, in particular, when matching document data on a next node with respect to a current node that has completed matching, matching is mainly performed between document data between the two nodes, for example, whether a transaction document matches a performance document, etc. Each checking task corresponds to a specific transaction order, that is, it is assumed that three consumers make an order through an online order making mode, and accordingly, the transaction system respectively generates three transaction orders and corresponds to three transaction receipt data, and the specific transaction receipt data has information such as a single number; correspondingly, when the track link is reached for processing, the generated track list also has identification information such as a list number and the like and is associated with the transaction list number; the same is true for the subsequent stock link and the distribution link, and the identification information such as the single number on a specific link has a binding relation with the single number in the previous node. Thus, after the first system receives the data, three collation tasks are generated and collation is performed. When checking is performed for one of the checking tasks, the document data on each node related to the same checking task can be found according to the association relation between the document data provided by the second system corresponding to each node and the identification information such as the single number, and then the document data on each node are checked in sequence according to the upstream and downstream relation between the nodes.

If the bill data associated with the bill data on the current node does not exist, is incomplete, is inconsistent or is inconsistent in state in the bill data of the next node corresponding to the current node, it can be determined that the bill data of the next node is not successfully matched. For example, three commodity objects are included in the transaction receipt, but only two of the commodity objects are included in the performance receipt, the matching fails, and so on. However, the reason for the failure of the matching may be due to the fact that the specific node has not been completely processed. For example, a trade order includes a dish to be processed and manufactured on site and a finished product to be directly packaged, at this time, in a performance system, two performance sheets may be split for the trade order, and the performance sheets are respectively performed by a kitchen department in a back ground and a shelf department in a front ground, and correspondingly, different performance document data may be respectively generated. However, the corresponding order of the front shelf may be completed relatively quickly, and the kitchen in the rear shelf may be processed and manufactured for a while, so that a relatively long time is required for completion. At this time, two different performance documents corresponding to the same transaction order may appear, where the two documents arrive at the first system at different times in sequence. At this time, when the next performance bill has not arrived, if the performance bill is matched, the number of commodity objects in the performance bill is found to be inconsistent with that in the transaction bill. At this time, in the embodiment of the present application, the matching is not determined as a matching failure directly, but the matching task is added to a retry queue, and after waiting for a preset time interval, the matching task is re-executed according to the document data newly provided by the second system. For example, in the verification task of the foregoing example, when matching document data on the performing node, if the performing document is found to be incomplete, the verification task may be added to the retry queue, and after a certain period of time, the verification may be performed again. That is, in the embodiment of the present application, the task processing on some nodes in one link is allowed to have time lag, and by means of continuous retry, the problem of data checking in the case that the time interval between the start node (for example, transaction payment) and the end node (for example, commodity delivery) in the same link is longer can be solved.

In the specific implementation, the retry queue of the first system may also store the current check results of each node in each check task, and when the check is performed next time, the matching may be performed downstream from the node that has completed the matching recently. For example, in a specific implementation, for a scenario such as a transaction link, the verification task state information stored in the retry queue of the first system may be as shown in table 4:

TABLE 4 Table 4

In particular, as described above, in the case of a specific implementation, a specific second system may split one order into a plurality of orders to process the orders respectively, so in order to avoid situations such as erroneous judgment of a first system, the second system may further determine, during processing of commodity object data on one of the nodes in the link, component structure information of document data generated on the node, and provide the component structure information to the first system when the document data is provided to the first system. The composition structure information can comprise specific bill splitting conditions, specific split bill quantity and other information. Such information may also be provided to the first system in the form of message packets. That is, assuming that the fulfillment system splits an order into three orders, there will be four message packages provided to the first system, one of which is the document data composition structure information corresponding to the specific splitting situation, and the other three of which corresponds to the three fulfilled document data. In general, the document data composition structure information may be provided to the first system first, where the first system also carries an identifier associated with the document identifier in the previous node, so that the first system may learn that when matching the document data on the previous node, three pieces of performing document data need to be matched, and after three pieces of performing document data are all aligned, if the document data match with the information of the commodity object type, the quantity, and the like in the previous node, it may be determined that the document data on the performing node is successfully matched.

In addition, in practical applications, there may be cases where document data provided by the second system is not standardized, for example, there are no necessary fields required, and so on. At this time, the first system may be further configured to store core field identification information of document data corresponding to each node identifier; after receipt of the bill data provided by the second system, judging whether the bill data contains the data on the core field according to the node identifier corresponding to the second system, if so, storing, otherwise, providing error prompt information for the second system, and requiring the second system to perform processing such as retransmission.

Moreover, there may be cases such as missed document data of the second system, missed receipt of the first system, etc., which all have a direct influence on the final verification result. In order to avoid this, the first system may also compare the document data received in the current period with the document data generation conditions and states in the second system corresponding to the current period (for example, every one hour, etc.), and if inconsistent document data exists, prompt the second system to perform retransmission compensation on the document data. In particular, the above-mentioned comparison operation may be implemented in various manners, for example, the first system may request the second system to obtain the bill data list information within a certain period of time, and then the first system performs the comparison, and so on. Therefore, missing documents can be found and compensated in time, and the reliability of the checking result is ensured.

Taking a commodity object transaction link as an example, referring to fig. 2, the nodes included in a specific transaction link are in turn: transaction, performance, inventory, delivery, where the second system includes a server for performing transaction, performance, inventory, delivery processes on the commodity objects, respectively, and the bill data provided to the first system includes transaction bills, performance bills, inventory bills, delivery bills, and the like, respectively.

After receiving the respective receipts, the first system may first perform verification, specifically including verification on the data integrity of the core field, and if not, may further require the second system to perform data complement processing. The specifically received document data may then be stored as a pool of document data, i.e. comprising a plurality of pieces of document data. A verification task is then generated from the document data and verified piece by piece. In addition, the bill data pool in the first system can be compared with the bill data in the second system in the period of time at regular intervals, and if the condition of missed sending or missed receiving is found, the second system can be prompted to carry out retransmission compensation on the bill data.

Wherein, specifically when checking is performed for each checking task, the first system is specifically configured to:

generating a checking task according to the transaction receipt received from the second system, and judging whether a performance receipt conforming to a corresponding matching rule exists or not in the received performance receipt data according to the matching rule between the transaction node and the performance node for one of the checking tasks;

if the matching is successful, judging whether an inventory document conforming to the corresponding matching rule exists or not according to the matching rule between the performance document and the inventory document from the received inventory document data;

if the matching is successful, judging whether the delivery bill conforming to the corresponding matching rule exists or not according to the matching rule between the stock bill and the delivery bill from the received delivery bill data,

if the match is successful, the verification task verifies.

That is, as shown in fig. 3, specifically, for a verification task, the verification may be performed from the transaction document, after the verification of the performance document is passed, the verification is performed on the inventory document, after the verification of the inventory document is passed, the verification is performed on the delivery document, after the verification of the delivery document is passed, the completion of the verification task may be determined, and the data matching is successful.

Other data processing links, including warehousing, dispatching, replenishment, etc., may also be processed in the manner described above, and will not be described in detail herein.

After the verification process is completed for a specific verification task, for a verification task that has not been successfully verified, for example, document data at a certain node is not successfully matched after repeated retries, then the document data may be added to the difference record. And finally, outputting information such as a difference report and the like, wherein the information can be provided for operators of relevant departments such as finance and the like. Alternatively, the information may be directly provided to other relevant departments, and after further processing, relevant financial statement and other information may be generated. The difference report may specifically store the task identifier that fails to pass the check, the document number corresponding to the associated starting node, and the information such as the node identifier that fails to pass the check. For example, the specific examples are shown in table 5:

TABLE 5

In summary, in the embodiment of the present application, by providing a first system independent of a second system where a service processing node in a specific link is located, and establishing a communication channel between the first system and the second system, document data generated in the second system may be provided to the first system through the communication channel, so that document data generated in the second system where different nodes on the same link are located may be checked in the first system. By the method, document data checking in the cooperative work of the distributed architecture and the plurality of business applications can be realized, the document data checking problem of a plurality of business links, a plurality of business servers and a complex link is solved, and the data processing flow on a specific business node is not influenced. In addition, since the bill data in the second system can be sent to the first system, the subsequent specific checking process is transparent for the second system, so that the condition that the bill data is tampered by a certain service node can be avoided, and the accuracy and the effectiveness of the checking result are ensured.

Example two

The second embodiment corresponds to the first embodiment, and from the perspective of the first system, a document data processing method is provided, referring to fig. 4, and the method specifically may include:

s401: acquiring node identification information, upstream and downstream relation information between nodes and document data matching rule information corresponding to the nodes, wherein the node identification information is included in a commodity object data processing link;

s402: generating a checking task after receiving bill data provided by a plurality of second systems; wherein the second system corresponds to a node in the commodity object data processing link;

S403: and checking the bill data on the nodes in the link aiming at the checking task.

In specific implementation, a message packet provided by the second system may be received through a message monitoring mechanism, where the message packet carries the document data.

And particularly, when generating the verification task, the verification task can be generated according to bill data provided by a second system corresponding to the initial node identification in the link. That is, for a certain document data received, if a node corresponding to a second system providing the document is a start node of a certain link, a verification task may be generated according to the document data.

Specifically, when checking, the document data on the nodes in the link can be checked in sequence from the initial node of the link according to the upstream-downstream relation information and the matching rule.

In specific implementation, the types of the commodity object data processing links to be processed are multiple, and the commodity object data processing links correspond to different starting nodes respectively; at this time, the target link type corresponding to the checking task may be determined according to the start node identifier in the checking task, and the document data may be checked according to the upstream-downstream relationship information corresponding to the target link type and the matching rule information.

When checking the bill data on the nodes in the link in turn, the current node which is matched in the checking task can be determined firstly, the bill data corresponding to the next node is taken out from the received bill data, and the bill data corresponding to the next node is matched and judged by utilizing the matching rule information between the current node and the next node; if the matching is successful, the next node is determined to be the current node which is matched, and matching judgment is carried out on document data corresponding to the next node until the matching judgment of the end node of the link is completed.

Wherein, in a specific scenario, the commodity object data processing link comprises a commodity object transaction link; the nodes included in the link are sequentially as follows according to the upstream-downstream relation: transaction, performance, inventory, delivery; the second system comprises a second system which is respectively used for carrying out transaction, performance, inventory and distribution processing on commodity objects; at this time, a verification task may be specifically generated according to the transaction document received from the second system; for one of the checking tasks, judging whether the performance document conforming to the corresponding matching rule exists or not according to the matching rule between the transaction node and the performance node from the received performance document data; if the matching is successful, judging whether an inventory document conforming to the corresponding matching rule exists or not according to the matching rule between the performance document and the inventory document from the received inventory document data; if the matching is successful, judging whether the delivery bill conforming to the corresponding matching rule exists or not according to the matching rule between the stock bill and the delivery bill in the received delivery bill data, and if the matching is successful, checking the passing of the checking task.

In addition, in the concrete implementation, if the bill data of the next node corresponding to a certain current node is not successfully matched, the checking task is added into a retry queue, and after waiting for a preset time interval, the checking task is re-executed according to the bill data newly provided by the second system.

And if the bill data associated with the bill data on the current node does not exist, is incomplete, is inconsistent or is inconsistent in state in the bill data of the next node corresponding to the current node, determining that the bill data of the next node is not successfully matched.

In addition, in specific implementation, the composition structure information of the bill data generated on the corresponding node provided by the second system can be received, so that the bill data on the node can be checked by combining with the composition structure information.

In order to ensure the integrity of the data, core field identification information of bill data corresponding to each node identification can be stored; after receipt of the bill data provided by the second system, judging whether the bill data contains the data on the core field according to the node identification corresponding to the second system, if so, storing, otherwise, providing error prompt information for the second system.

In addition, in order to avoid the conditions of missed sending of the second system, missed receiving of the first system and the like, the received bill data in the current period can be compared with the generation conditions and states of the bill data in the corresponding second system according to the preset period, and if inconsistent bill data exist, the second system is prompted to carry out retransmission compensation on the bill data.

In specific implementation, a link customization request provided by a target user can be received, wherein the request carries node identification information, upstream and downstream relation information between nodes and document data matching rule information corresponding to the nodes, wherein the node identification information is included in the link.

Example two

The second embodiment also corresponds to the first embodiment, and from the perspective of the second system, a document data processing method is provided, referring to fig. 5, and the method specifically may include:

s501: processing commodity object data on a target node in a commodity object data processing link and generating bill data;

s502: and providing the bill data to a first system so that the first system generates a checking task, and checking the bill data on the nodes in the link according to the pre-stored upstream and downstream relation information between the nodes and the matching rule by taking the checking task as a unit.

For the details of the second embodiment and the third embodiment, reference may be made to the descriptions of the first embodiment, and the details are not repeated here.

Corresponding to the embodiment, the embodiment of the application also provides a document data processing device, referring to fig. 6, the device specifically may include:

an information obtaining unit 601, configured to obtain node identification information, upstream-downstream relationship information between nodes, and document data matching rule information corresponding to the nodes, which are included in the commodity object data processing link;

a verification task generating unit 602, configured to generate a verification task after receiving document data provided by a plurality of second systems; wherein the second system corresponds to a node in the commodity object data processing link;

and the checking unit 603 is configured to check document data on a node in the link for the checking task.

In particular, the apparatus may further include:

and the monitoring unit is used for receiving the message packet provided by the second system through a message monitoring mechanism, wherein the message packet carries the bill data.

Wherein the collation task generation unit may specifically be configured to:

and generating the checking task according to bill data provided by a second system corresponding to the initial node identification in the link.

The checking unit may be specifically configured to, for the checking task, sequentially check document data on nodes in the link from a start node of the link according to the upstream-downstream relationship information and the matching rule.

The commodity object data processing link types to be processed are multiple, and respectively correspond to different starting nodes;

the collation unit may be specifically configured to: and determining a target link type corresponding to the checking task according to the starting node identification in the checking task, and checking the bill data according to the upstream and downstream relation information corresponding to the target link type and the matching rule information.

Specifically, the collation unit may specifically be configured to:

determining a current node which is matched in the checking task, extracting bill data corresponding to a next node from the received bill data, and carrying out matching judgment on the bill data corresponding to the next node by utilizing matching rule information between the current node and the next node;

if the matching is successful, the next node is determined to be the current node which is matched, and matching judgment is carried out on document data corresponding to the next node until the matching judgment of the end node of the link is completed.

Wherein the commodity object data processing link comprises a commodity object transaction link; the nodes included in the link are sequentially as follows according to the upstream-downstream relation: transaction, performance, inventory, delivery; the second system comprises a second system which is respectively used for carrying out transaction, performance, inventory and distribution processing on commodity objects;

the collation unit may be specifically configured to:

generating a verification task according to the transaction receipt received from the second system;

for one of the checking tasks, judging whether the performance document conforming to the corresponding matching rule exists or not according to the matching rule between the transaction node and the performance node from the received performance document data;

if the matching is successful, judging whether the delivery bill conforming to the corresponding matching rule exists or not according to the matching rule between the stock bill and the delivery bill in the received delivery bill data, and if the matching is successful, checking the passing of the checking task.

In addition, the apparatus may further include:

And the retry unit is used for adding the checking task into a retry queue if the bill data of the next node corresponding to a certain current node is not successfully matched, and re-executing the checking task according to the bill data newly provided by the second system after waiting for a preset time interval.

In order to avoid erroneous judgment of the first system, the apparatus may further include:

and the structure information receiving unit is used for receiving the composition structure information of the bill data generated on the corresponding node provided by the second system so as to check the bill data on the node by combining the composition structure information.

In addition, the apparatus may further include:

the field identification information storage unit is used for storing core field identification information of bill data corresponding to each node identification;

and the field judging unit is used for judging whether the bill data contains the data on the core field according to the node identification corresponding to the second system after receiving the bill data provided by the second system, if so, storing, otherwise, providing error prompt information for the second system.

In order to avoid the situation of missed transmission or missed reception, the device may further include:

and the comparison unit is used for comparing the receipt data received in the current period with the receipt data generation conditions and states in the corresponding second systems according to the preset period, and prompting the second systems to carry out retransmission compensation on the receipt data if inconsistent receipt data exists.

The information obtaining unit may specifically be configured to: and receiving a link customization request provided by a target user, wherein the request carries node identification information, upstream and downstream relation information between nodes and document data matching rule information corresponding to the nodes included in the link.

Corresponding to the embodiment, the embodiment of the application also provides a bill data processing device, referring to fig. 7, the device specifically may include:

the bill data generating unit 701 is configured to process commodity object data on a target node in a commodity object data processing link, and generate bill data;

and the document data providing unit 702 is configured to provide the document data to a first system, so that the first system generates a verification task, and the verification task is used as a unit to verify the document data on the nodes in the link according to the pre-stored upstream-downstream relationship information between the nodes and the matching rule.

In addition, the embodiment of the application also provides electronic equipment, which comprises:

one or more processors; and

Fig. 8 illustrates an architecture of a computer system, which may include a processor 810, a video display adapter 811, a disk drive 812, an input/output interface 813, a network interface 814, and a memory 820, among others. The processor 810, video display adapter 811, disk drive 812, input/output interface 813, network interface 814, and memory 820 may be communicatively coupled via a communication bus 830.

The processor 810 may be implemented by a general-purpose CPU (Central Processing Unit ), a microprocessor, an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc., for executing relevant programs to implement the technical solutions provided herein.

The Memory 820 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory ), static storage device, dynamic storage device, or the like. The memory 820 may store an operating system 821 for controlling the operation of the electronic device 800, and a Basic Input Output System (BIOS) for controlling low-level operation of the electronic device 800. In addition, a web browser 823, a data storage management system 824, a document data processing system 825, and the like may also be stored. The document data processing system 825 may be an application program that specifically implements the operations of the foregoing steps in the embodiments of the present application. In general, when implemented in software or firmware, the relevant program code is stored in memory 820 and executed by processor 810.

The input/output interface 813 is used to connect with an input/output module to realize information input and output. The input/output module may be configured as a component in a device (not shown) or may be external to the device to provide corresponding functionality. Wherein the input devices may include a keyboard, mouse, touch screen, microphone, various types of sensors, etc., and the output devices may include a display, speaker, vibrator, indicator lights, etc.

Network interface 814 is used to connect communication modules (not shown) to enable communication interactions of the present device with other devices. The communication module may implement communication through a wired manner (such as USB, network cable, etc.), or may implement communication through a wireless manner (such as mobile network, WIFI, bluetooth, etc.).

Bus 830 includes a path for transferring information between components of the device (e.g., processor 810, video display adapter 811, disk drive 812, input/output interface 813, network interface 814, and memory 820).

In addition, the electronic device 800 may also obtain information of specific acquisition conditions from the virtual resource object acquisition condition information database 841 for making condition judgment, and so on.

It is noted that although the above-described devices illustrate only the processor 810, video display adapter 811, disk drive 812, input/output interface 813, network interface 814, memory 820, bus 830, etc., the device may include other components necessary to achieve proper operation in an implementation. Furthermore, it will be understood by those skilled in the art that the above-described apparatus may include only the components necessary to implement the present application, and not all the components shown in the drawings.

From the above description of embodiments, it will be apparent to those skilled in the art that the present application may be implemented in software plus a necessary general purpose hardware platform. Based on such understanding, the technical solutions of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform the methods described in the embodiments or some parts of the embodiments of the present application.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for a system or system embodiment, since it is substantially similar to a method embodiment, the description is relatively simple, with reference to the description of the method embodiment being made in part. The systems and system embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.

The document data processing method, device and system provided by the application are described in detail, and specific examples are applied to illustrate the principles and embodiments of the application, and the description of the above examples is only used for helping to understand the method and core ideas of the application; also, as will occur to those of ordinary skill in the art, many modifications are possible in view of the teachings of the present application, both in the detailed description and the scope of its applications. In view of the foregoing, this description should not be construed as limiting the application.

Claims

1. A document data processing system, comprising:

the first system and a plurality of second systems, the second systems correspond to nodes in the commodity object data processing link; wherein a communication channel is arranged between the first system and the second system; the commodity object data processing link comprises a commodity object transaction processing link or a commodity object warehousing processing link;

The first system is configured to obtain node identification information, upstream and downstream relationship information between nodes, and document data matching rule information between nodes included in the link, generate a verification task after receiving document data provided by the second system, and sequentially verify document data on nodes in the link according to the upstream and downstream relationship information and the matching rule, starting from a starting node of the link for the verification task;

when the first system performs the sequential checking, determining a current node which is matched in the checking task, taking out bill data corresponding to a next node from the received bill data, and performing matching judgment on the bill data corresponding to the next node by using matching rule information between the current node and the next node; if the matching is successful, the next node is determined to be the current node which is matched, and matching judgment is carried out on document data corresponding to the next node until the matching judgment of the end node of the link is completed.

2. The system of claim 1, wherein the system further comprises a controller configured to control the controller,

the first system is specifically configured to sequentially check document data on nodes in the link from a start node of the link according to the upstream-downstream relationship information and the matching rule.

3. A document data processing method, comprising:

acquiring node identification information of a plurality of nodes included in a commodity object data processing link, upstream and downstream relation information among the nodes and bill data matching rule information corresponding to the nodes; the commodity object data processing link comprises a commodity object transaction processing link or a commodity object warehousing processing link;

for the checking task, starting from the initial node of the link, sequentially checking bill data on the nodes in the link according to the upstream-downstream relation information and the matching rule;

when the sequential checking is carried out, determining a current node which is matched in the checking task, taking out bill data corresponding to a next node from the received bill data, and carrying out matching judgment on the bill data corresponding to the next node by utilizing matching rule information between the current node and the next node; if the matching is successful, the next node is determined to be the current node which is matched, and matching judgment is carried out on document data corresponding to the next node until the matching judgment of the end node of the link is completed.

4. A method according to claim 3, further comprising:

and receiving a message packet provided by the second system through a message monitoring mechanism, wherein the message packet carries the bill data.

5. The method of claim 3, wherein the step of,

the generating a collation task includes:

6. The method of claim 3, wherein the step of,

the types of the commodity object data processing links are multiple, and respectively correspond to different initial nodes;

the sequentially checking the bill data on the nodes in the link comprises the following steps:

and determining a target link type corresponding to the checking task according to the starting node identification in the checking task, and checking the bill data according to the upstream and downstream relation information corresponding to the target link type and the matching rule information.

7. The method of claim 3, wherein the step of,

the commodity object data processing link comprises a commodity object transaction link; the nodes included in the link are sequentially as follows according to the upstream-downstream relation: transaction, performance, inventory, delivery; the second system comprises a second system which is respectively used for carrying out transaction, performance, inventory and distribution processing on commodity objects;

8. A method according to claim 3, further comprising:

if the bill data of the next node corresponding to a certain current node is not successfully matched, adding the checking task into a retry queue, and after waiting for a preset time interval, re-executing the checking task according to the bill data newly provided by the second system.

9. The method of claim 8, wherein the step of determining the position of the first electrode is performed,

if the bill data associated with the bill data on the current node does not exist, is incomplete, is inconsistent or is inconsistent in state in the bill data of the next node corresponding to the current node, determining that the bill data of the next node is not successfully matched.

10. A method according to claim 3, further comprising:

and receiving the composition structure information of the bill data generated on the corresponding node provided by the second system so as to verify the bill data on the node by combining the composition structure information.

11. A method according to claim 3, further comprising:

storing core field identification information of bill data corresponding to each node identification;

after receipt of the bill data provided by the second system, judging whether the bill data contains the data on the core field according to the node identification corresponding to the second system, if so, storing, otherwise, providing error prompt information for the second system.

12. A method according to claim 3, further comprising:

and comparing the received bill data in the current period with the generation conditions and states of the bill data in the corresponding second system according to the preset period, and prompting the second system to carry out retransmission compensation on the bill data if inconsistent bill data exists.

13. The method of claim 3, wherein the step of,

the obtaining node identification information, upstream and downstream relation information between nodes and document data matching rule information corresponding to the nodes, which are included in the commodity object data processing link, includes:

and receiving a link customization request provided by a target user, wherein the request carries node identification information, upstream and downstream relation information between nodes and document data matching rule information corresponding to the nodes included in the link.

14. A document data processing method, comprising:

processing commodity object data on a target node in a commodity object data processing link and generating bill data; the commodity object data processing link comprises a commodity object transaction processing link or a commodity object warehousing processing link;

providing the bill data to a first system so that the first system generates a checking task, and sequentially checking the bill data on the nodes in the link from the initial node of the link according to the upstream and downstream relation information and the matching rule between the pre-stored nodes by taking the checking task as a unit;

15. A document data processing apparatus, comprising:

the information obtaining unit is used for obtaining node identification information of a plurality of nodes included in the commodity object data processing link, upstream and downstream relation information among the nodes and bill data matching rule information corresponding to the nodes; the commodity object data processing link comprises a commodity object transaction processing link or a commodity object warehousing processing link;

The checking unit is used for sequentially checking bill data on nodes in the link according to the upstream and downstream relation information and the matching rule from the initial node of the link aiming at the checking task; when the sequential checking is carried out, determining a current node which is matched in the checking task, taking out bill data corresponding to a next node from the received bill data, and carrying out matching judgment on the bill data corresponding to the next node by utilizing matching rule information between the current node and the next node; if the matching is successful, the next node is determined to be the current node which is matched, and matching judgment is carried out on document data corresponding to the next node until the matching judgment of the end node of the link is completed.

16. A document data processing apparatus, comprising:

the bill data generating unit is used for processing commodity object data on a target node in the commodity object data processing link and generating bill data; the commodity object data processing link comprises a commodity object transaction processing link or a commodity object warehousing processing link;

The bill data providing unit is used for providing the bill data for the first system so that the first system generates a checking task, the checking task is taken as a unit, and the bill data on the nodes in the link are checked in sequence from the initial node of the link according to the upstream and downstream relation information and the matching rule between the pre-stored nodes;

17. An electronic device, comprising:

one or more processors; and