CN111353841A

CN111353841A - Document data processing method, device and system

Info

Publication number: CN111353841A
Application number: CN201811575016.XA
Authority: CN
Inventors: 黄锴
Original assignee: Alibaba Group Holding Ltd
Current assignee: Hema China Co Ltd
Priority date: 2018-12-21
Filing date: 2018-12-21
Publication date: 2020-06-30
Anticipated expiration: 2038-12-21
Also published as: CN111353841B

Abstract

The embodiment of the application discloses a document data processing method, a device and a system, wherein the system comprises: the second system is used for processing the commodity object data on the target node in the link, generating receipt data and providing the receipt data to the first system through the communication channel; and the first system is used for acquiring node identification information, upstream and downstream relation information among nodes and bill data matching rule information among the nodes, generating a checking task after receiving the bill data provided by the second system, and checking the bill data on the nodes in the link aiming at the checking task. By the embodiment of the application, document data check in the distributed architecture and the cooperative work of a plurality of business applications can be realized.

Description

Document data processing method, device and system

Technical Field

The present application relates to the technical field of document data processing, and in particular, to a method, an apparatus, and a system for processing document data.

Background

In the commodity object sales system, the financial data collation is one of the more important. Taking the transaction link with the largest data volume as an example, the conventional data checking scheme mainly solves the problem of traditional store data checking. Under the scene, the user takes away the goods after completing payment at the cashier desk, and can complete the transaction immediately, and the transaction payment and the goods delivery can be considered to be completed at the same time, so that the transaction link is simple. In addition, the transaction amount of the scene is small, the system usually adopts centralized deployment, all data are stored in the same database, all services are in the same database and are completed synchronously, and therefore checking can be completed by ensuring data consistency through database transactions.

However, in the online and offline combined mode of "new retail", etc., the retailer can provide information of the commodity object through an online application program (App) provided by the "new retail" platform, and the user can browse, purchase, etc. through the App on the line. Meanwhile, the retailer can set up an off-line physical store, and the user can purchase the commodity object through the off-line physical store. In this case, the online order may be subjected to a series of processes such as shipment from an offline physical store, and finally delivered to a destination designated by the user. In the off-line physical store, various processes such as warehousing of some commodities, adjustment of commodities, replenishment of commodities and the like are required. In the above scenarios of transaction, warehousing, transferring, replenishment, etc., a long processing link is usually involved.

In the new retail mode, the transaction scene is taken as an example, and the online and offline transaction system has the characteristics that the transaction order quantity is large, online and offline are integrated, a small amount of transactions occur in stores, and most of transactions are online and offline. For the online ordering situation, specific commodities need to be sent to the user by a distributor to complete, and the whole transaction link is completed only after the user signs the commodities. Transaction payment and merchandise delivery are thus accomplished asynchronously, typically 1 hour to several days apart. Moreover, the whole transaction link may be completed by a plurality of different business departments, even different application systems, for example, the application used in the transaction process and the application used in the delivery process may be independent from each other, and these data may be distributed in the databases of the business servers of the different application systems, so that the data consistency cannot be directly guaranteed through the database transaction.

Therefore, how to efficiently check document data in a complex link becomes a technical problem to be solved by those skilled in the art.

Disclosure of Invention

The application provides a document data processing method, a document data processing device and a document data processing system, which can realize document data checking in a distributed architecture and multiple service applications in cooperative work, avoid influences on data processing flows on specific service nodes, avoid the conditions that document data is tampered by one of the service nodes and the like, and ensure the accuracy and the effectiveness of checking results.

The application provides the following scheme:

a document data processing system comprising:

a first system and a plurality of second systems, the second systems corresponding to nodes in the commodity object data processing link; wherein the first system and the second system have a communication channel therebetween;

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

and the first system is used for acquiring node identification information, upstream and downstream relation information among nodes and bill data matching rule information among the nodes, receiving the bill data provided by the second system, generating a checking task, and checking the bill data on the nodes in the link aiming at the checking task.

A document data processing method comprises the following steps:

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

after receiving the bill data provided by the plurality of second systems, generating checking tasks; wherein the second system corresponds to a node in a 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 comprises the following steps:

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

and providing the bill data to a first system so that the first system can generate a check task, the check task is taken as a unit, and the bill data on the nodes in the link are checked according to the pre-stored upstream and downstream relation information between the nodes and the matching rule.

A document data processing apparatus comprising:

the information acquisition unit is used for acquiring node identification information, upstream and downstream relation information among nodes and receipt data matching rule information corresponding to the nodes, wherein the node identification information, the upstream and downstream relation information and the receipt data matching rule information are included in a commodity object data processing link;

the checking task generating unit is used for generating checking tasks after receiving the receipt data provided by the plurality of second systems; wherein the second system corresponds to a node in a 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 receipt data generating unit is used for processing the commodity object data on the target node in the commodity object data processing link and generating receipt data;

and the bill data providing unit is used for providing the bill data to a first system so that the first system can generate a check task, the check task is taken as a unit, and the bill data on the nodes in the link are checked according to the pre-stored upstream and downstream relation information between the nodes and the matching rule.

An electronic device, comprising:

one or more processors; and

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

According to the specific embodiments provided herein, the present application discloses the following technical effects:

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

In the checking process, document data on nodes in the link can be checked in sequence from the initial node of the link according to the upstream and downstream relation information between 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 retry mechanism can solve the difficult problem of checking the transaction payment and the commodity delivery at a long time interval. Moreover, through a task retry mechanism, the task state can be set to be successful only after all the nodes on each link are checked, and the condition that no income is missed is ensured.

Of course, it is not necessary for any product to achieve all of the above-described advantages at the same time for the practice 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 needed to be used 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 it is obvious for those skilled in the art to obtain other drawings without creative efforts.

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

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

FIG. 3 is a schematic illustration of a verification 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 embodiments of the present application;

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

FIG. 7 is a schematic diagram of a second apparatus provided by 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 technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments that can be derived from the embodiments given herein by a person of ordinary skill in the art are intended to be within the scope of the present disclosure.

In the embodiment of the present application, in order to be able to check related document data in a complex link scenario, a check server is provided (of course, there may be other names, and in the embodiment of the present application, they are collectively referred to as "first system"). The first system may be independent of a particular business system server. Of course, the independence in the embodiments of the present application may specifically mean a functional independence, and specifically, may be separately deployed on one or more dedicated physical devices. Or, the system can also be deployed in a server of one of the service systems, but needs to be logically isolated from the specific service processing logic; still alternatively, since the verification result provided by the first system is mainly provided to a related system such as finance system for use in the embodiment of the present application, 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, 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, which may be referred to as a second system in this embodiment) or even 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 the unified reconciliation processing.

In order to achieve the above purpose, a communication connection may be established between the first system and the second system, so that information may be communicated with each other. For example, in a specific implementation, a message communication mechanism may be adopted, 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 monitoring mechanism, and may be capable of identifying a message in the message packet, and so on.

The second system can match the condition information after generating the specific bill data, and if the state of the bill data conforms to the condition information, a corresponding message packet can be generated and sent to the first system. For example, the specific condition may be that document data needs to be sent once it is generated, or that processing operations on a specific node are sent once they are completed, and so on. That is, the status of the document data in the second system may be automatically sent to the first system by way of a message once it meets some predetermined condition related to financial reconciliation. And then, the specific document data is checked on the first system, and the first system and the second system are independent from each other, so that on one hand, the influence on the data processing flow on specific service nodes can be avoided, on the other hand, the document data can be prevented from being tampered by one of the service nodes, and the accuracy and the effectiveness of the check result can be ensured.

In order to perform a specific checking operation, the first system may store in advance 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. For example, for a transaction link, specifically included nodes may be transaction, performance, inventory, delivery, etc., where a "transaction" is the initial node of the link, the first node downstream is "performance," the next node is "inventory," the next node is "delivery," etc. In addition, when checking document data related to finance and the like, in particular, the document data generated by different nodes are usually checked. For example, after a certain consumer completes one order placement online, a corresponding transaction document is generated in a transaction link, then the consumer enters a fulfillment link to process and generate a corresponding fulfillment document, and after fulfillment, the consumer enters an inventory link to process and generate a corresponding inventory document, and the like. Specifically, when checking the receipt data, the method mainly determines whether the receipt data generated for the transaction receipt in each subsequent link is accurate, complete and consistent, is completed on time or not according to the specifically generated transaction receipt, and the like.

After receiving specific document data, the first system can generate a checking task according to the document data provided by the second system corresponding to the starting node in a specific link, and then checks the document data on the node in the link aiming at the checking task. In the preferred implementation manner, in the process of executing a specific checking task, document data in each link on the downstream of the link on the link can be checked in sequence from the starting node, if a business link is successfully matched, the next business link can be checked, if the previous link is not successfully matched, the checking task can be put into a retry queue to wait for the next task scheduling, and the like.

By the mode, when the distributed architecture and the multiple business applications work cooperatively, the document data is checked, the problem of checking the document data related to multiple business links, multiple business servers and complex links is solved, the data processing flow on specific business nodes cannot be influenced, the document data can be prevented from being tampered by one of the business nodes, and the accuracy and the effectiveness of the checking result are guaranteed. In addition, if a certain link in the link is not successfully checked, the checking task can be continuously retried, and the task timing retry mechanism can solve the difficult problem of checking the transaction payment and the commodity delivery at a long time interval. Moreover, through a task retry mechanism, the task state can be set to be successful only after all the nodes on each link are checked, and the condition that no income is missed is ensured.

The following describes in detail a specific technical solution provided in an embodiment of the present application.

Example one

First, the first embodiment provides a document data processing system, and 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 the commodity object data processing link; wherein, a communication channel is arranged between the first system 101 and the second system 102;

the second system 102 is configured to process commodity object data on one of the nodes 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, generate a checking task after receiving document data provided by the second system, and check document data on nodes in the link for the checking task.

For example, in a trading scenario, the specific commodity object data processing link may specifically be a trading link, and in a commodity warehousing scenario, the specific commodity object data processing link may be a commodity warehousing link, and the like. In different links, there will usually be a plurality of specific service nodes, the processing logic of which is distributed over a plurality of different second systems.

In this embodiment, first, node identification information, upstream and 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 the first system in advance. For example, in one implementation, the information stored in the first system may specifically be as shown in table 1:

TABLE 1

The specific link includes which nodes, the upstream and downstream relationships between the nodes, and matching rules corresponding to the nodes, and the like, and may be specifically customized by the user. That is to say, for different users, it is specifically necessary to check document data on which nodes may be different, and therefore, in order to meet different requirements of different users, a specific customized operation entry may be provided for the user, so that the server may obtain node information included in a specific link, an upstream-downstream relationship between nodes, and a matching rule corresponding to the nodes by receiving customized information submitted by the user.

In addition, in the specific implementation, the specific matching rule is not limited to between two nodes, and some rules may be required to be satisfied between multiple nodes, and the like. For example, still taking a transaction link scenario as an example, when document data on a specific fulfillment node is matched, a corresponding matching rule may be a matching rule between the transaction node and the fulfillment node, including whether the name and the number of the commodity object are consistent. In specific implementation, information about nodes, matching rules and the like in a specific link may be configured in a code writing manner, or a corresponding configuration interface may be provided, so that a user may perform configuration in a manner of performing visual configuration in the configuration interface, and the like.

Upon storing the information in the first system, the second system may provide the specifically generated document data to the first system. In this embodiment, one link includes a plurality of nodes, functions of these nodes are distributed in a plurality of different service systems, and a plurality of servers distributed in different systems need to cooperate together to complete a specific data processing task on a certain link. For example, also taking the transaction link as an example, when a consumer purchases a certain commodity object through an App on a line, a transaction order may be generated by the transaction system first, and financial-related document information may be generated; then, the information (including order number, commodity object name, quantity, etc.) in the trade order can be provided to the fulfillment system, and the fulfillment system can generate a corresponding fulfillment task according to the information in the trade order, correspond to the fulfillment order, and correspondingly generate a financial-related fulfillment document. After the fulfillment operation is completed, the specific processing flow also enters an inventory system and a delivery system to respectively generate corresponding inventory documents and delivery documents, and the like. In the process that the second system in each link processes the task in the node, corresponding document data can be generated, and the document data mainly can embody data required by departments such as finance and the like. In this embodiment, after the specific document data is generated in the second system, the specific document data may be generated according to preset condition information, where the condition information may include a specific document type, a corresponding state trigger condition, and the like. Thus, the second system can determine whether the state of the specific document data meets the specific conditions, and if so, the state can be provided to the first system. The preset condition information may be set according to the specific situation of data required in the related system such as finance. For example, for a "fulfillment" link, it may be that when a certain fulfillment form becomes "completed" state, corresponding fulfillment form data is provided to the first system, and so on.

That is to say, the second system generates corresponding receipt data in the process of processing data generated in an actual service scene on a specific service node, and once the data meets a 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 already provides specific document data to the first system at the document data generation stage, and the subsequent specific checking operations are all completed in the first system, so that even if document data on a certain node is different in the checking process, the second system corresponding to the node cannot attempt to evade penalty by means of data tampering.

In particular, the first system may receive document data provided by the second system in a variety of ways. For example, in one of the manners, as described above, the second system may actively provide specific document data to the first system, and may specifically send the specific document data by means of a message, and at this time, the first system may receive the specific document data by means of monitoring messages of the respective second systems. Of course, in other manners, the request may be obtained by the first system to the second system, and so on.

In short, the first system can obtain specific document data from the second system, wherein the number of the second systems is multiple, and the specific second system usually generates multiple document data concurrently, so that the number of the document data received by the first system is also multiple. In addition, for the same business order (for example, a trade order generated after a certain customer user makes an order on line, or a replenishment order generated after a certain merchant initiates replenishment, etc.), the business order is processed at different links on the same link for different time periods, and the time periods may be separated from each other for a longer time period, so that the same checking task may be completed in a longer time period, and during the time period, more document data is continuously received from the second system. Therefore, the processing manner of the first system may specifically be that after receiving the document data of the second system, the document data may be first stored locally in the first system. In addition, each piece of document data carries information such as a message source, for example, information such as a specific node identifier from which second system the document data comes, and even directly, so that the first system can know the node identifier corresponding to each piece of document 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	Trading
10002	2001	Trading
			10003	2002	Performing contract
10004	2003	Stock keeping
			……	……	……

That is, at the same time, the document data received by the first system may include multiple transaction documents provided by the second system of the transaction node, multiple fulfillment documents provided by the second system of the fulfillment node, and so on. And then, the first system can also generate a checking task according to the received document data and then check item by item.

The specific checking task is started from the initial node of the link, and for the same service order, the second system corresponding to the initial node performs the processing of the first link firstly, the document data corresponding to the initial node is generated firstly, and the document data generated in the second systems on other downstream nodes are generated after the initial node completes the processing of the first link usually. In addition, when the time checking is actually carried out, the document data generated by the starting node is mainly judged, and whether the document data which is matched with the document data and has data consistency exists on each subsequent downstream node or not is judged. Therefore, when generating the checking tasks, 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 specific implementation, because the node identifier included in each link and the upstream-downstream relationship between the node identifier and the node identifier are also stored in the first system, the starting node identifier of each specific link can be obtained, and the received document data carries the specific second system identifier or the node identifier. 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 check tasks are generated according to the document data, and so on.

The method comprises the steps of obtaining document data corresponding to the initial nodes, generating a plurality of check tasks according to the document data corresponding to the initial nodes, and determining the link type corresponding to each check task. For example, if the starting node of the transaction link is a transaction node and the starting node of the dispatching link is dispatching, if a certain document data corresponds to the transaction node, a checking task can be generated according to the document data, and the document data can be determined to be document data generated in the transaction link, and then checking can be performed according to upstream and downstream node information in the transaction link and matching rule information during specific checking. If a certain document data corresponds to a dispatching node, a checking task can be generated according to the document data, but the document data can be determined to be the document data generated in the dispatching link at the moment, and then checking can be performed according to upstream and downstream node information in the dispatching link and matching rule information when checking is specifically performed.

In the specific implementation, as the checking tasks are multiple and the checking of the same checking task is usually completed after a long time, the checking tasks can be added into the task queue according to the information such as the time sequence and the like. Subsequently, specific checking tasks can be taken out from the queue, and checking is carried out item by item. 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

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

Specifically, when each checking task is checked, the document data on the nodes in the link may be sequentially checked from the start node according to the upstream and downstream relationship information and the matching rule. Specifically, under the condition of having multiple different link types, the nodes included in the different link types, the upstream and downstream relationships between the nodes, the matching rules, and the like may all be different, and therefore, the target link type corresponding to the checking task may also be determined according to the starting node identifier in the checking task, and then the document data is checked according to the upstream and downstream relationship information corresponding to the target link type and the matching rule information. For example, if the starting node identifier corresponding to a certain checking task is "transaction", the corresponding link type may be determined as a transaction link, and further, it may be determined that the second node in the link is fulfillment, the third node is inventory, and the last node is delivery, and so on. And then, matching the document data on each node in turn according to the sequence of the upstream and the downstream.

After determining information such as a specific link type, specifically, when checking is performed, the first system may first extract document data corresponding to a next node from received document data for a current node that has completed matching in the checking task, then perform matching judgment on the document data corresponding to the next node by using matching rule information between the current node and the next node, and if matching is successful, use 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 matching of the next node is performed.

It should be noted that, specifically, when matching document data on a next node of a current node that has completed matching, matching is mainly performed between document data of the two nodes, for example, whether a transaction document is matched with a performance document or not, and the like. Each checking task corresponds to a specific transaction order, that is, assuming that three consumers place orders simultaneously in an online order placing mode, correspondingly, the transaction system respectively generates three transaction orders and corresponds to three transaction document data, and the specific transaction document data has information such as a document number and the like; correspondingly, when the transaction order reaches the fulfillment link for processing, the generated fulfillment order also has identification information such as the order number and the like, and is associated with the transaction order number; the same is true for the subsequent stock link and the subsequent distribution link, and the identification information such as the single number on a certain link and the like has a binding relationship with the single number in the previous node. Thus, after the first system receives the data, three verification tasks are generated and are respectively verified. When one of the checking tasks is checked, the document data on each node related to the same checking task can be found through the document data provided by the second system corresponding to each node and the association relation between identification information such as a document number and the like, and then the document data on each node is sequentially checked according to the upstream and downstream relation between the nodes.

If the document data associated with the document data on the current node does not exist, is incomplete, is inconsistent or has a different state in the document data of the next node corresponding to the current node, it can be determined that the document data of the next node is not successfully matched. For example, if three item objects are included in the transaction document, but only two are included in the performance document, the match fails, and so on. However, the reason for the failure of matching may be due to the fact that a specific node is not completely processed. For example, a certain trade order includes a dish to be processed and made on site and a finished product that can be directly packaged, at this time, in the fulfillment system, the trade order may be split into two fulfillment documents, which are respectively fulfilled by a kitchen department in the back end and a shelf department in the front end, and accordingly, different fulfillment document data may also be generated respectively. However, the fulfillment list corresponding to the front shelf may be completed relatively quickly, and the back kitchen requires a period of time for processing, fabrication, and the like, and thus, a relatively long time is required for completion. At this time, there may be a case where two different fulfillment documents correspond to the same transaction order and arrive at the first system at different times in sequence. At this time, if the fulfillment documents are matched when the latter fulfillment documents do not arrive, the situation that the number of the commodity objects in the fulfillment documents does not match the transaction documents is found. At this time, in the embodiment of the present application, the checking task is not directly determined as a matching failure, but the checking task is added to a retry queue, and after waiting for a preset time interval, the checking task is re-executed according to the document data newly provided by the second system. For example, in the reconciliation task in the above example, when the document data on the fulfillment node is matched and the fulfillment document is found to be incomplete, the reconciliation task may be added to the retry queue, and after a while, the reconciliation may be performed again. That is, in the embodiment of the present application, there is a time lag in allowing task processing on a part of nodes in a link, and by means of continuous retry, the problem of data checking in the case of a long time interval from an initial node (for example, transaction payment) to an end node (for example, commodity delivery) in the same link can be solved.

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

TABLE 4

As described above, in a specific implementation, a specific second system may split one order into a plurality of orders to process the orders, and therefore, in order to avoid a situation such as a misjudgment of the first system, the second system may determine the composition structure information of the receipt data generated at a node in the link while processing the commodity object data at the node, and when providing the receipt data to the first system, provide the composition structure information to the first system. The composition structure information may include information such as a specific document splitting condition, a specific number of documents split, and the like. This information may also be provided to the first system in the form of a message packet. That is, assuming that the fulfillment system splits an order into three fulfillment documents, there are four message packets provided to the first system, one of which is document data composition structure information corresponding to a specific splitting situation, and the other three of which are corresponding to three fulfillment document data. In general, the document data composition structure information may be provided to the first system at first, where the document data composition structure information also carries an identifier associated with the document identifier in the previous node, so that the first system may know that, when matching the document data on the node, three pieces of fulfillment document data need to be matched, and after the three pieces of fulfillment document data are all aligned, if the document data are consistent with the information such as the category and the number of the commodity object in the previous node, it may be determined that the document data on the fulfillment node is successfully matched.

In addition, in practical applications, there may be situations where the document data provided by the second system is not normal, e.g., there are no necessary fields required, etc. At this time, the first system may also be configured to store core field identification information of the document data corresponding to each node identification; after receiving 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 the bill data, otherwise, providing error prompt information to the second system, and requesting the second system to perform processing such as retransmission.

Moreover, there may be situations such as missed document data transmission from the second system, or missed document data reception from the first system, which may directly affect the result of the final core. In order to avoid this, the first system may further compare the document data received in the current period with the generation condition and the state of the document data in the respective corresponding second systems according to a preset period (e.g., every hour, etc.), and if there is inconsistent document data, prompt the second system to perform retransmission compensation on the document data. In the specific implementation, the comparison operation may be implemented in various ways, for example, the first system may request the second system to obtain the document data list information in a certain time period, 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 the commodity object trade link as an example, referring to fig. 2, the nodes included in the specific trade link are, in order according to the upstream and downstream relationship: transaction, fulfillment, inventory, delivery, in which case the second system comprises servers for performing transaction, fulfillment, inventory, delivery processing, respectively, on the item object, and the document data provided to the first system comprises transaction documents, fulfillment documents, inventory documents, delivery documents, respectively, and so on.

After receiving the respective documents, the first system may perform verification, specifically including verifying data integrity of the core field, and if the data integrity is not complete, the second system may also be required to perform data completion processing. Then, the received document data may be stored as a document data pool, that is, the document data includes a plurality of pieces of document data. Then, a checking task is generated according to the document data, and the checking is carried out item by item. In addition, the bill data pool in the first system can be compared with the bill data in the second system at regular time intervals, and if the condition of missing sending or missing receiving is found, the second system can be prompted to carry out retransmission compensation on the bill data.

Specifically, when checking each checking task, the first system is specifically configured to:

generating checking tasks according to the transaction documents received from the second system, and judging whether a performance document meeting a corresponding matching rule exists in the received performance document data according to the matching rule between the transaction node and the performance node for one checking task;

if the matching is successful, judging whether the stock documents which accord with the corresponding matching rules exist in the received stock document data according to the matching rules between the performance documents and the stock documents;

if the matching is successful, judging whether the distribution bill which accords with the corresponding matching rule exists in the received distribution bill data according to the matching rule between the stock bill and the distribution bill,

if the match is successful, the check task checks through.

That is, as shown in fig. 3, specifically for a check task, the transaction document may be checked, the inventory document may be checked after the fulfillment document is checked, the delivery document may be checked after the inventory document is checked, and the check task may be completed and the data matching may be successful after the delivery document is checked.

Other data processing links including warehousing of goods, adjusting goods, replenishing goods and the like can also be processed in the above manner, and the processing is not described in detail one by one.

After the reconciliation process is completed for a specific reconciliation task, for a reconciliation task which has not been successfully reconciled, for example, document data at a certain node still fails to be successfully matched after repeated retries for a plurality of times, the document data can be added into the difference record. Finally, the information such as difference report forms can be output, and the information can be provided for operators in related departments such as finance and the like. Or, the information can be directly provided to other related operation departments, and after further processing, the information such as a related financial statement and the like can be generated. The difference report may specifically store information such as a specific task identifier that fails to be checked, a document number corresponding to the associated starting node, and a node identifier that fails to be checked. For example, the following may be specifically mentioned in table 5:

TABLE 5

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

Example two

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

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

s402: after receiving the bill data provided by the plurality of second systems, generating checking tasks; wherein the second system corresponds to a node in a 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, the message packet provided by the second system may be received through a message monitoring mechanism, where the message packet carries the document data.

Specifically, when the reconciliation task is generated, the reconciliation task can be generated according to the bill data provided by the second system corresponding to the initial node identifier in the link. That is, for a received piece of document data, if the node corresponding to the second system providing the document is the starting node of a link, a check task may be generated according to the document data.

Specifically, when checking is performed, document data on nodes in the link may be checked sequentially from the start node of the link according to the upstream and downstream relationship information and the matching rule.

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

Specifically, when document data on nodes in the link are checked in sequence, a current node which is matched in the checking task is determined, document data corresponding to a next node is taken out from the received document data, and matching judgment is performed on the document data corresponding to the next node by using matching rule information between the current node and the next node; and if the matching is successful, determining the next node as the current node which is matched, and performing matching judgment 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 and downstream relation: trading, performing, stocking and delivering; the second system comprises a second system used for carrying out transaction, performance, inventory and distribution processing on the commodity objects respectively; at this time, a verification task may be generated specifically according to the transaction document received from the second system; for one of the checking tasks, judging whether a fulfillment document meeting a corresponding matching rule exists in received fulfillment document data according to the matching rule between the transaction node and the fulfillment node; if the matching is successful, judging whether the stock documents which accord with the corresponding matching rules exist in the received stock document data according to the matching rules between the performance documents and the stock documents; if the matching is successful, judging whether the distribution documents meeting the corresponding matching rules exist in the received distribution document data according to the matching rules between the stock documents and the distribution documents, and if the matching is successful, the checking task is checked to be passed.

In addition, in specific implementation, if the document 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 a preset time interval is waited, the checking task is executed again according to the document data newly provided by the second system.

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

In addition, in specific implementation, the component structure information of the document data generated on the corresponding node provided by the second system may also be received, so that the document data on the node is checked in combination with the component structure information.

In order to ensure the integrity of the data, core field identification information of the bill data corresponding to each node identification can be stored; and after receiving 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 the bill data, and otherwise, providing error prompt information for the second system.

In addition, in order to avoid the situations of missed sending of the second system, missed receiving of the first system and the like, the document data received in the current period can be compared with the generation situation and the state of the document data in the second system respectively corresponding to the document data according to a preset period, and if inconsistent document data exists, the second system is prompted to carry out retransmission compensation on the document 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.

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, and referring to fig. 5, the method may specifically include:

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

s502: and providing the bill data to a first system so that the first system can generate a check task, the check task is taken as a unit, and the bill data on the nodes in the link are checked according to the pre-stored upstream and downstream relation information between the nodes and the matching rule.

For the parts that are not described in detail in the second embodiment and the third embodiment, reference may be made to the descriptions in the first embodiment, and details thereof are not repeated here.

Corresponding to the second embodiment, an embodiment of the present application further provides a document data processing apparatus, and referring to fig. 6, the apparatus may specifically include:

an information obtaining unit 601, configured to obtain 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 commodity object data processing link;

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

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

In a specific implementation, 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.

The verification task generating unit may be specifically configured to:

and generating the checking task according to the bill data provided by the second system corresponding to the starting node identifier in the link.

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

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

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

Specifically, the checking unit may be specifically configured to:

determining a current node which is matched in the checking task, taking out document data corresponding to a next node from the received document data, and performing matching judgment on the document data corresponding to the next node by using matching rule information between the current node and the next node;

and if the matching is successful, determining the next node as the current node which is matched, and performing matching judgment 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 and downstream relation: trading, performing, stocking and delivering; the second system comprises a second system used for carrying out transaction, performance, inventory and distribution processing on the commodity objects respectively;

the verification unit may be specifically configured to:

generating a reconciliation task based on the transaction document received from the second system;

for one of the checking tasks, judging whether a fulfillment document meeting a corresponding matching rule exists in received fulfillment document data according to the matching rule between the transaction node and the fulfillment node;

if the matching is successful, judging whether the distribution documents meeting the corresponding matching rules exist in the received distribution document data according to the matching rules between the stock documents and the distribution documents, and if the matching is successful, the checking task is checked to be passed.

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 a next node corresponding to a 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 the first system misjudgment, 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 the 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 or not according to the node identifier corresponding to the second system after receiving the bill data provided by the second system, and if so, storing the bill data, otherwise, providing error prompt information to the second system.

In order to avoid the condition of missing sending or missing receiving, the device may further include:

and the comparison unit is used for comparing the bill data received in the current period with the generation condition and the state of the bill data in the second system respectively corresponding to the bill data according to the preset period, and prompting the second system to perform retransmission compensation on the bill data if inconsistent bill data exists.

The information obtaining unit may specifically be configured to: 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 receipt data matching rule information corresponding to the nodes.

Corresponding to the three phases of the embodiment, the embodiment of the present application further provides a document data processing apparatus, referring to fig. 7, the apparatus may specifically include:

a receipt data generation unit 701, configured to process commodity object data on a target node in a commodity object data processing link and generate receipt data;

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

In addition, an embodiment of the present application further provides an electronic device, including:

one or more processors; and

FIG. 8 illustrates an architecture of a computer system that may include, in particular, 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. The processor 810, the video display adapter 811, the disk drive 812, the input/output interface 813, the network interface 814, and the memory 820 may be communicatively connected by 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 (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solution provided by the present Application.

The Memory 820 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random access Memory), a static storage device, a dynamic storage device, or the like. The memory 820 may store an operating system 821 for controlling operation of the electronic device 800, 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, and a document data processing system 825, among others, may also be stored. The document data processing system 825 may be an application program that implements the operations of the foregoing steps in this embodiment of the application. In summary, when the technical solution provided in the present application is implemented by software or firmware, the relevant program codes are stored in the memory 820 and called for execution by the processor 810.

The input/output interface 813 is used for connecting an input/output module to realize information input and output. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.

The network interface 814 is used for connecting a communication module (not shown in the figure) to realize communication interaction between the device and other devices. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).

Bus 830 includes a pathway for communicating information between various components of the device, such as 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 pickup conditions from the virtual resource object pickup condition information database 841 for performing condition judgment, and the like.

It should be noted that although the above-mentioned devices only show the processor 810, the video display adapter 811, the disk drive 812, the input/output interface 813, the network interface 814, the memory 820, the bus 830, etc., in a specific implementation, the devices may also include other components necessary for normal operation. Furthermore, it will be understood by those skilled in the art that the apparatus described above may also include only the components necessary to implement the solution of the present application, and not necessarily all of the components shown in the figures.

From the above description of the embodiments, it is clear to those skilled in the art that the present application can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the present application may be essentially implemented or a part contributing to the prior art may be embodied 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., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method described in the embodiments or some parts of the embodiments of the present application.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the system or system embodiments are substantially similar to the method embodiments and therefore are described in a relatively simple manner, and reference may be made to some of the descriptions of the method embodiments for related points. The above-described system and system embodiments are only illustrative, wherein the units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

The document data processing method, device and system provided by the application are introduced in detail, a specific example is applied in the text to explain the principle and implementation of the application, and the description of the above embodiment is only used to help understand the method and core ideas of the application; meanwhile, for a person skilled in the art, according to the idea of the present application, the specific embodiments and the application range may be changed. In view of the above, the description should not be taken as limiting the application.

Claims

1. A document data processing system, comprising:

2. The system of claim 1,

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

3. A document data processing method is characterized by comprising the following steps:

4. The method of 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,

the generating of the checking task comprises:

6. The method of claim 3,

the checking of the document data on the nodes in the link includes:

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.

7. The method of claim 6,

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

the checking the document data on the nodes in the link in sequence comprises:

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

8. The method of claim 6,

the checking the document data on the nodes in the link in sequence comprises:

9. The method of claim 8,

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 and downstream relation: trading, performing, stocking and delivering; the second system comprises a second system used for carrying out transaction, performance, inventory and distribution processing on the commodity objects respectively;

the checking the document data on the nodes in the link in sequence comprises:

10. The method of claim 8, further comprising:

and 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.

11. The method of claim 10,

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

12. The method of 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 check the bill data on the node by combining the composition structure information.

13. The method of claim 3, further comprising:

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

and after receiving 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 the bill data, and otherwise, providing error prompt information for the second system.

14. The method of claim 3, further comprising:

and comparing the bill data received in the current period with the generation condition and the state of the bill data in the second system respectively corresponding to the bill data according to a preset period, and prompting the second system to perform retransmission compensation on the bill data if inconsistent bill data exists.

15. The method of claim 3,

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

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 receipt data matching rule information corresponding to the nodes.

16. A document data processing method is characterized by comprising the following steps:

17. A document data processing apparatus, comprising:

18. A document data processing apparatus, comprising:

19. An electronic device, comprising:

one or more processors; and