CN111291335A

CN111291335A - Bill data processing method and device, computer equipment and storage medium

Info

Publication number: CN111291335A
Application number: CN202010062626.0A
Authority: CN
Inventors: 郑罗海
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-01-19
Filing date: 2020-01-19
Publication date: 2020-06-16
Anticipated expiration: 2040-01-19
Also published as: CN111291335B

Abstract

The embodiment of the application discloses a bill data processing method, a bill data processing device, computer equipment and a storage medium, wherein the method comprises the following steps: responding to the state change operation executed aiming at the electronic bill, acquiring business auxiliary information associated with the electronic bill, and determining the bill state of the electronic bill according to the business auxiliary information; if the bill state of the electronic bill is a first state and the first server node is determined to have the state change authority, adjusting the bill state of the electronic bill from the first state to a second state; and transferring the electronic bill having the second status to the status change address according to the status change address associated with the status change authority. By adopting the embodiment of the application, the efficiency of exception handling of the electronic bill can be improved.

Description

Bill data processing method and device, computer equipment and storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for processing ticket data, a computer device, and a storage medium.

Background

When the electronic bill has abnormal information and needs to be subjected to abnormal processing (for example, invalidation processing), a server node of a tax office associated with the electronic bill needs to determine user information of a user currently holding the electronic bill (for example, a mailbox address of an individual user for receiving the electronic bill) in advance through transaction record information on a chain so as to inform the user of transferring the electronic bill to the server node through the mailbox address, that is, when the server node performs abnormal processing on a certain electronic bill, the server node needs to rely on the user holding the electronic bill to perform bill transfer, and the operation is very complicated, so that the efficiency of performing the abnormal processing on the electronic bill by the server node is reduced.

Content of application

The embodiment of the application provides a bill data processing method and device, computer equipment and a storage medium, and the efficiency of exception handling of electronic bills can be improved.

In one aspect, an embodiment of the present invention provides a method for processing ticket data, where the method is performed by a first server node in a blockchain network, and includes:

responding to the state change operation executed aiming at the electronic bill, acquiring business auxiliary information associated with the electronic bill, and determining the bill state of the electronic bill according to the business auxiliary information;

if the bill state of the electronic bill is a first state and the first server node is determined to have the state change authority, adjusting the bill state of the electronic bill from the first state to a second state;

and transferring the electronic bill having the second status to the status change address according to the status change address associated with the status change authority.

In one aspect, an embodiment of the present invention provides a ticket data processing apparatus, which operates in a first server node in a blockchain network, and includes:

the determining module is used for responding to state change operation executed aiming at the electronic bill, acquiring business auxiliary information associated with the electronic bill and determining the bill state of the electronic bill according to the business auxiliary information;

a first adjusting module, configured to adjust a ticket status of the electronic ticket from a first status to a second status if the ticket status of the electronic ticket is the first status and it is determined that the first server node has a status change authority;

and the transfer module is used for transferring the electronic bill with the second state to the state change address according to the state change address associated with the state change authority.

Wherein, the determining module comprises:

the authentication unit is used for responding the state change operation executed by the first object aiming at the display interface to which the electronic bill belongs and authenticating the first object;

a first obtaining unit, configured to obtain service auxiliary information associated with the first object when authentication is successful;

a second obtaining unit, configured to determine, according to the service auxiliary information, an association relationship that the first object has with a user in the electronic ticket, and obtain, according to the association relationship, transaction record information associated with the electronic ticket;

and the first determining unit is used for determining the bill state of the electronic bill according to the transaction record information.

Wherein, the authentication unit comprises:

an obtaining subunit, configured to obtain, in response to a state change operation performed by a first object on a display interface to which an electronic ticket belongs, an illegal user behavior comparison table from an associated server node associated with the first server node; the illegal user behavior comparison table comprises at least one illegal user; an illegal user is a user which is accumulated in the block chain network and performs the state change operation to reach an operation threshold value;

and a determining subunit, configured to search the illegal user behavior comparison table for the first object, and determine the first object as a legal user when the first object is not searched.

Wherein, the determining module further comprises:

the first sending unit is used for responding to the state change operation executed by the second object aiming at the display interface to which the electronic bill belongs and sending a transaction inquiry request aiming at the electronic bill to the block chain link points in the block chain network; the transaction inquiry request is used for acquiring transaction record information associated with the electronic bill in the block chain network; said second object is subordinate to a tax authority in said electronic ticket;

the second determining unit is used for determining the circulation route of the electronic bill according to the time stamp of each transaction record information in the transaction record information;

a third determining unit, configured to determine the circulation route as service auxiliary information associated with the electronic ticket;

and the fourth determining unit is used for determining the bill state of the electronic bill according to the service auxiliary information.

Wherein the service auxiliary information further comprises an associated ticket associated with the first object;

the above-mentioned device still includes:

and the second adjusting module is used for screening the electronic bills matched with the state change period from the related bills and adjusting the screened bill states of the electronic bills into the second state.

Wherein, above-mentioned device still includes:

and the verification module is used for verifying the state change authority of the first server node according to the multi-signature address corresponding to the circulation route.

Wherein, above-mentioned verification module includes:

a third obtaining unit, configured to obtain ticket information in the electronic ticket from a first multiple signature address associated with the electronic ticket if the circulation route is a first circulation route; the first circulation route is formed when the electronic bill is circulated from the billing user having the same regional attribute as the second object to the personal user; said first multi-signed address being determined by both an address of said first server node and an address of said individual user; the address of the first server node is determined by a first public key of the first server node;

a signature unit, configured to sign the electronic ticket based on a private key of the first server node, to obtain signature information of the electronic ticket;

a second sending unit, configured to send a signature verification request to a block link point in the block chain network based on the signature information, so that the block link point verifies the signature information based on the first public key to obtain a verification result;

and a fifth determining unit, configured to obtain the signature verification result returned by the block link point, and determine that the first server node has a status change permission according to the signature verification result.

Wherein, above-mentioned device still includes:

the acquisition module is used for acquiring the bill information in the electronic bill from a second multiple signature address associated with the electronic bill if the transfer route is a second transfer route; the second circulation route is formed when the electronic bill is circulated from the individual user to the reimbursement user having the different regional attribute from the second object; the second multiple signature address is determined by the address of the second server node corresponding to the tax bureau to which the reimbursement user belongs and the address of the reimbursement user; the address of the second server node is determined by a second public key of the second server node;

a sending module, configured to send a status change notification request for the electronic ticket to the second server node, so that the second server node adjusts the ticket status of the electronic ticket from the first status to a second status when the second server node has the status change right.

One aspect of the present application provides a node device, including: a processor, a memory, a network interface;

the processor is connected to a memory and a network interface, wherein the network interface is used for providing a data communication function, the memory is used for storing a computer program, and the processor is used for calling the computer program to execute the method in the above aspect in the embodiment of the present application.

An aspect of the present application provides a computer-readable storage medium storing a computer program comprising program instructions that, when executed by a processor, perform the method of the above-mentioned aspect of the embodiments of the present application.

In this embodiment of the present application, a first server node in a block chain network may quickly determine a ticket state of an electronic ticket and a state change authority of the first server node based on service auxiliary information of the electronic ticket. Wherein the state changing authority is determined by the multiple signature address of the electronic bill. It should be understood that if the multi-signed address contains the address of the first server node, it is understood that the first server node has state change authority. In this case, the first server node having the status change authority may directly adjust the ticket status of the electronic ticket having the first status to the second status, and transfer the electronic ticket having the second status to the status change address, thereby improving the efficiency of exception handling of the electronic ticket.

Drawings

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

Fig. 1 is a schematic structural diagram of a network architecture according to an embodiment of the present application;

fig. 2 is a schematic view of a scenario for performing data interaction according to an embodiment of the present application;

fig. 3 is a scene schematic diagram of an electronic bill provided in an embodiment of the present application;

FIG. 4 is a schematic flow chart of a bill data processing method according to an embodiment of the present application;

fig. 5 is a schematic view of a scenario for determining a ticket status of an electronic ticket according to an embodiment of the present application;

FIG. 6 is a schematic flow chart of a bill data processing method according to an embodiment of the present application;

fig. 7 is a scene schematic diagram of adjusting a ticket state of an electronic ticket according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a bill data processing device according to an embodiment of the present application;

fig. 9 is a schematic diagram of a node device according to 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, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

Please refer to fig. 1, which is a schematic structural diagram of a network architecture according to an embodiment of the present application. As shown in fig. 1, the network architecture includes a block-link point for operating a block-chain network and a user terminal cluster. The block link node system refers to a system for performing data sharing between nodes. The block link point system may include a plurality of nodes. As shown in fig. 1, the block link point system may specifically include node 2000a, node 2000b, node 2000c, …, and node 2000 n. The user terminal cluster may include a plurality of user terminals, as shown in fig. 1, and may specifically include a user terminal 3000a, a user terminal 3000b, user terminals 3000c and …, and a user terminal 3000 n.

In the block chain node system, when each node works normally, the transaction record information of the electronic bill associated with the node can be acquired so as to maintain the shared data in the block chain node system. In order to ensure the information intercommunication in the blockchain node system, a network connection can be established between each node in the blockchain node system, so as to transmit data through the network connection. For example, when any node in the block link point system acquires the transaction record information, other nodes in the block link point system may acquire the transaction record information according to a consensus algorithm, and store the transaction record information as data in shared data, so that the data stored in all nodes in the block link point system are consistent.

Each node in the block chain node point system has a corresponding node identifier, and each node in the block chain node point system can store other node identifiers having a network connection relationship with the current node, so that the generated block is broadcast to other nodes in the block chain node point system according to the node identifiers of the other nodes. Each node may maintain a node identifier list as shown in the following table, and store the node name and the node identifier in the node identifier list correspondingly. The node identifier may be an IP (Internet Protocol) address and any other information that can be used to identify the node, and table 1 only illustrates the IP address as an example.

TABLE 1

Node name	Node identification
		Node 1	117.114.151.174
Node 2	117.116.189.145
		…	…
Node N	119.123.789.258

It should be understood that each node in the block-node point-by-point system may interact with traffic data with each user terminal in the user terminal cluster. It is understood that the embodiments of the present application may select a node in the block-link node system shown in fig. 1 as the first server node in the block-link network. The first server node may be a node having a virtual asset transfer function, such as a tax platform. For example, the embodiment of the present application may use the node 2000a in the block-link node system as the first server node. The first server node may perform service data interaction with each user terminal in the user terminal cluster.

Each ue in the ue cluster shown in fig. 1 may include: and intelligent terminals with service data access functions, such as smart phones, tablet computers, desktop computers and the like. It is to be appreciated that embodiments of the present application can select one ue among the ues in the ue cluster shown in fig. 1 as the ue associated with the first server node (e.g., node 2000 a). For example, in this embodiment, the user terminal 3000a in the user terminal cluster may be used as the user terminal associated with the first server node.

It should be appreciated that the node 2000a may obtain the business assistance information associated with the electronic ticket in response to a state change operation performed by a target object at the user terminal 3000a for the electronic ticket. The target object may be the first object or the second object. The first object may include a billing user in the electronic ticket, an associated personal user (i.e. a consuming user) of the electronic ticket, and a reimbursement user in the electronic ticket, which is not limited herein. The second object may comprise a local taxing authority in the electronic ticket to which the invoicing user is affiliated. It can be understood that the local tax bureau to which the invoicing user belongs and the local tax bureau to which the reimbursement user belongs in the electronic bill may have the same or different regional attribute information. It is not limited herein. For example, the tax office to which the invoicing user belongs may be the tax office in area A, and the tax office to which the reimbursement user belongs may be the tax office in area B.

The state change operation may be a trigger operation executed by the target object corresponding to the user terminal 3000a in the target area of the display interface to which the electronic ticket belongs, where the trigger operation may include a contact operation such as a click or a long press, or may include a non-contact operation such as a voice or a gesture, and is not limited herein.

It is understood that the business assistance information may include the ticket information in the electronic ticket and the transaction record information of the electronic ticket. Further, the node 2000a may determine the ticket status of the electronic ticket according to the service assistance information. Wherein, the bill state can include a first state and a second state. It is understood that the first state refers to a state (e.g., a to-be-voided state) in which the electronic ticket needs to be exception-processed due to a return of sales, an error in billing information, a termination of taxable services, and the like. The second state refers to a state in which the electronic ticket has been invalidated by exception processing (for example, a invalidated state), in other words, a state in which the electronic ticket has been invalidated. Additionally, the ticket status may also include a reimburseable status and a reimbursed status. It is understood that the reimburseable status refers to a status that the tax authority in which the electronic bill is located can reimburse the electronic bill. The reimbursed state refers to the state that the tax authority where the electronic bill is located has reimbursed the invoice.

It should be understood that if the ticket status of the electronic ticket is the first status and the node 2000a has the right to change the status of the electronic ticket, the node 2000a may adjust the ticket status of the electronic ticket from the first status to the second status. The state change authority refers to an authority that the node 2000a can adjust the ticket state of the electronic ticket. Further, the node 2000a may acquire a status change address associated with the status change authority, and transfer the electronic ticket having the second status to the status change address. The status change address refers to an address to which the node 2000a transfers the electronic ticket when performing exception processing (e.g., invalidation processing). It should be appreciated that the electronic ticket will expire after the electronic ticket is transferred to the status change address. At this time, the node 2000a may write the transaction record information of the electronic invoice transferred to the status change address into the blockchain in the blockchain network shown in fig. 1, so that other nodes in the blockchain network may update the transaction record information associated with the electronic ticket, so as to improve the security of the transaction record information of the electronic ticket.

For easy understanding, please refer to fig. 2, which is a schematic diagram of a scenario for performing data interaction according to an embodiment of the present application. As shown in fig. 2, the server node 100 may be a segment node (e.g., node 2000a) in the segment node system corresponding to fig. 1, the ue 300 may be any ue (e.g., ue 3000b) in the ue cluster corresponding to fig. 1, and the ue 300 may be a ue a. The server node 200 may be an associated server node with which the server node 100 is associated, and the server node 200 may be a blockchain node in the blockchain network shown in fig. 1 described above.

The server node 200 may store an illegal user behavior comparison table therein. The illegal user behavior comparison table is used for storing the information table of the illegal user. The illegal user behavior comparison table may contain at least one illegal user. The illegal user refers to a user whose execution state change operation accumulated in the block chain network shown in fig. 1 reaches an operation threshold (for example, 20 times).

For example, when a certain user B performs a status change operation 20 times within a certain period (e.g. 30 days), in other words, the user B invalidates 20 electronic tickets within 30 days, the node in the blockchain network may add the user B to the illegal user behavior comparison table shown in fig. 2, so that the user B cannot continue to perform the status change operation on other electronic tickets.

It can be understood that, if a certain illegal user (e.g., the illegal user a) does not perform the state change operation any more within a period of time (e.g., 30 days) added to the illegal user behavior comparison table, at this time, the server node 200 may delete the illegal user a from the illegal user behavior comparison table, so that the illegal user a may recover the identity of the legal user, and thus may perform exception handling on the electronic ticket normally.

It should be understood that, in the embodiment of the present application, the user a corresponding to the user terminal 300 may be referred to as a target object. The target object may be a first object or a second object. The first object may include a billing user in the electronic ticket a, an individual user (i.e. a consuming user) associated with the electronic ticket a, and a reimbursement user in the electronic ticket a, which is not limited herein. The second object may comprise a tax authority of the place to which the invoicing user is affiliated in the electronic ticket a. It is understood that, as shown in fig. 2, the ticket information of the electronic ticket a and the target area for performing the status change operation may be displayed in the display interface a of the user terminal 300.

For easy understanding, please refer to fig. 3, which is a schematic view of a scene of an electronic ticket provided in an embodiment of the present application. As shown in fig. 3, the ticket information of the electronic ticket a may specifically include basic information 1, basic information 2, basic information 3, basic information 4, basic information 5, and basic information 6. The basic information 1 may include an invoice code, an invoice number, an invoicing date and a check code of the electronic bill. The basic information 2 may include a stamp of the tax bureau of the area to which the invoicing user corresponding to the electronic ticket a belongs. The basic information 3 may include basic information of the reimbursement user in the electronic ticket a, for example, basic information such as the name, address, and contact address of the purchaser. The basic information 4 may include basic information such as taxable services, amount, unit price, amount, tax rate, and tax amount. The basic information 5 may include basic information of the invoicing user in the electronic ticket a, for example, basic information such as the name, address, and contact address of the seller. The basic information 6 may include a stamp of the invoicing user, etc.

It should be understood that the electronic ticket a may be an electronic ticket in a game scenario, for example, a game user (i.e., a buyer) may purchase a batch of property equipment (e.g., armor for defense property, broadsword for attack property, wings for speed property, etc.) for a game character in a game a using virtual assets such as game gold or game diamonds, and a service provider (i.e., a seller) corresponding to the game a may issue an electronic ticket for the game user.

Optionally, the electronic ticket a may also be an electronic ticket in a financial scenario, for example, a user (an individual user) may have a meal at a certain restaurant in the area a, and after the meal is finished, a service provider (a seller, i.e., a ticketing user) corresponding to the restaurant may issue an electronic ticket for the individual user, so that the individual user may reimburse a unit or an enterprise (a buyer, i.e., a reimbursement user) where the individual user is located. The electronic ticket a may also be an electronic ticket in other scenarios, and is not limited herein.

As shown in fig. 2, if the state change operation responded by the server node 100 is triggered by a first object (i.e. the billing user, the individual user, and the reimbursement user associated with the electronic ticket a), the electronic ticket a that the server node 100 performs the state change operation may be the electronic ticket held by the first object. It can be understood that the user a can perform a state change operation on a target area of the display interface a to which the electronic ticket a belongs. The state change operation may include a contact operation such as a click or a long press, or may include a non-contact operation such as a voice or a gesture, and is not limited here.

Further, the server node 100 may authenticate the user a in response to the state change operation. It is understood that the server node 100 may obtain the illegal user behavior comparison table from the server node 200 associated with the server node 100 in response to the status change operation. The server node 100 may search the illegitimate user behavior comparison table for the user a.

If the server node 100 searches the user a in the illegal user behavior comparison table, the server node 100 may determine the user a as an illegal user, and at this time, the server node 100 may generate an alarm prompt message and return the alarm prompt message to the user terminal 300 where the user a is located. The alarm prompt message is used for reminding the user A that the state change operation cannot be executed on the electronic bill. For example, "you can't invalidate the electronic ticket XXXX temporarily when the number of times of invalidating the electronic ticket reaches the upper limit in the month, and if there is a need to go to the tax administration in XX to eliminate the illegal user identity".

If the server node 100 does not search the user a in the illegal user behavior comparison table, the server node 100 may determine the user a as a legal user, and at this time, the server node 100 successfully authenticates the user a. Further, the server node 100 may determine the ticket status of the electronic ticket a. Wherein it is understood that the server node can obtain the service assistance information associated with the electronic ticket a. The business assistance information may include basic information of the first object (e.g., name, address, contact phone, and affiliated entity, etc.) and ticket information in the electronic ticket. Further, the server node 100 may determine the association relationship between the user a and the user in the electronic ticket according to the service assistance information. It is understood that the user a may be a billing user in the electronic ticket, the user a may also be a reimbursement user in the electronic ticket, and the user a may also be an individual user associated with the electronic ticket, which is not limited herein.

At this time, the server node 100 may acquire the transaction record information associated with the electronic ticket a according to the association relationship. For example, if the first object is an individual user (e.g., individual user a) in the electronic ticket, the first server node may determine that the transaction record information of the electronic ticket may transfer the electronic ticket to the individual user a for the invoicing user in the electronic ticket. If the first object is an reimbursement user (e.g., reimbursement user A) in the electronic ticket, the transaction record information for the electronic ticket may transfer the electronic ticket to reimbursement user A for the individual user associated with the electronic ticket.

Further, the server node 100 may determine the ticket status of the electronic ticket a according to the transaction record information of the electronic ticket a, and verify the status change authority of the server node 100 according to the transaction record information. If the ticket status of the electronic ticket a is the first status and the server node 100 has the status change authority, the server node 100 may adjust the ticket status of the electronic ticket from the first status to the second status. Then, the server node 100 may acquire a status change address associated with the status change authority, and transfer the electronic ticket a having the second status to the status change address based on the private key of the server node 100 to invalidate the electronic ticket a.

Optionally, if the state change operation responded by the server node 100 is triggered by the second object (i.e., the tax bureau corresponding to the server node 100), the electronic bill for the state change operation performed by the server node 100 may be an electronic bill determined by the first object through a telephone call, a field transaction, or a virtual electronic bill queried by national departments such as a business administration department and a public security department. The electronic bill is a fraud behavior that the electronic bill is not issued according to the actual situation, and when tax paying units and individuals issue invoices in the commodity transaction process for some needs, the electronic bill is falsely issued by falsifying names of commodities, commodity quantity, commodity unit price and amount, even by using a relatively familiar relationship.

The service assistance information acquired by the server node may further comprise an associated ticket associated with the first object if the user associated with the electronic ticket (e.g., billing user, personal user, reimbursement user, etc.) belongs to the first object of the virtual electronic ticket. Further, the server node may screen the electronic tickets matching the status change period from the associated tickets, and adjust the ticket status of the screened electronic tickets to the second status. It is understood that if the first object has other illegal activities such as virtual invoicing, the server node may screen the first object for the transfer of electronic tickets to the change-of-state address within the change-of-state period (e.g., the last month or last half month) to invalidate the electronic tickets.

The specific implementation manner of the first server node transferring the electronic ticket to the status change address may refer to the following embodiments corresponding to fig. 4 to 7.

Further, please refer to fig. 4, which is a flowchart illustrating a method for processing ticket data according to an embodiment of the present application. The method may be performed by a first server node in a blockchain network. As shown in fig. 4, the method may include:

s101, responding to the state change operation executed for the electronic bill, acquiring the business auxiliary information associated with the electronic bill, and determining the bill state of the electronic bill according to the business auxiliary information.

Specifically, the target object corresponding to the user terminal may perform the state change operation in the target area of the display interface to which the electronic ticket belongs. The state change operation may include a contact operation such as a click or a long press, or may include a non-contact operation such as a voice or a gesture, and is not limited herein. Further, the first server node may be responsive to the state change operation to obtain the business assistance information associated with the electronic ticket. Wherein, the service auxiliary information can comprise the bill information in the electronic bill and the transaction record information of the electronic bill. At this time, the first server node may determine the ticket status of the electronic ticket according to the service assistance information.

The first server node may be the server node 100 corresponding to fig. 2, and the server node 100 may be a node (e.g., the node 2000a) in the block-link node system corresponding to fig. 1. The ue may be the ue 300 corresponding to fig. 2, and the ue 300 may be a ue (e.g., the ue 3000b) in a ue cluster corresponding to fig. 1.

It should be understood that the target object corresponding to the user terminal may be the first object or the second object. The first object may include a billing user in the electronic ticket, an individual user (i.e. a consuming user) associated with the electronic ticket, and a reimbursement user in the electronic ticket, which is not limited herein. The second object may comprise a local taxing authority in the electronic ticket to which the invoicing user is affiliated.

It is understood that, if the target object for performing the status change operation on the electronic ticket is the first object, the first server node may authenticate the first object in response to the status change operation. It is understood that, as shown in fig. 2, the server node 100 (i.e., the first server node) may obtain the illegal user behavior comparison table from the server node 200 (i.e., the associated server node) associated with the server node, and search the illegal user behavior comparison table for the first object.

Wherein, the illegal user behavior comparison table may contain at least one illegal user. The illegal user is a user whose execution state change operation accumulated in the block chain network shown in fig. 1 reaches an operation threshold within a certain period. It can be understood that, if a certain illegal user (e.g., the illegal user a) does not perform the state change operation any more within a period of time (e.g., 30 days) added to the illegal user behavior comparison table, at this time, the server node 200 may delete the illegal user a from the illegal user behavior comparison table, so that the illegal user a may recover the identity of the legal user, and thus may perform exception handling on the electronic ticket normally.

It should be understood that, if the first server node searches the first object in the illegal user behavior comparison table, the first server node may determine the first object as an illegal user, and at this time, the first server node may generate an alarm prompt message and return the alarm prompt message to the user terminal where the first object is located. The alarm prompt message is used for reminding the first user that the state change operation cannot be executed on the electronic bill. For example, "you can't invalidate the electronic ticket XXX temporarily when the number of times of invalidating the electronic ticket reaches the upper limit in the month, and if you need to go to the tax administration in XX to eliminate the illegal user identity".

If the first server node does not search the first object in the illegal user behavior comparison table, the first server node may determine the first object as a legal user, and at this time, the embodiment of the present application may consider that the first server node successfully authenticates the first object. Further, the first server node may obtain traffic assistance information associated with the first object. Wherein the service auxiliary information may include basic information (e.g., name, address, contact number, and affiliated entity, etc.) of the first object and ticket information in the electronic ticket. Further, the first server node may determine the association relationship between the first object and the user in the electronic ticket according to the ticket information in the service assistance information. It is to be understood that the first object may be a billing user in the electronic ticket, the first object may be a reimbursement user in the electronic ticket, and the first object may be an individual user associated with the electronic ticket, which is not limited herein.

Further, the first server node may obtain the transaction record information associated with the electronic ticket according to the association relationship. For example, if the first object is an individual user (e.g., individual user a) in the electronic ticket, the first server node may determine that the transaction record information of the electronic ticket may transfer the electronic ticket to the individual user a for the invoicing user in the electronic ticket. If the first object is an reimbursement user (e.g., reimbursement user A) in the electronic ticket, the transaction record information for the electronic ticket may transfer the electronic ticket to reimbursement user A for the individual user associated with the electronic ticket. It should be appreciated that the first server node may determine the instrument status of the electronic instrument based on the transaction record information.

Wherein, the bill state can include a first state and a second state. It is understood that the first state refers to a state in which the electronic ticket needs to be invalidated due to a return of sales, an error in billing information, a termination of taxable services, and the like. The second state is a state in which the electronic ticket has been invalidated, in other words, a state in which other people do not have an authority to transfer the electronic ticket. Additionally, the ticket status may also include a reimburseable status and a reimbursed status. It is understood that the reimburseable status refers to a status that the tax authority in which the electronic bill is located can reimburse the electronic bill. The reimbursed state refers to the state that the tax authority where the electronic bill is located has reimbursed the invoice.

If the target object for performing the state change operation on the electronic bill is triggered by the second object (namely, the tax bureau corresponding to the first server node), the electronic bill for performing the state change operation on the first server node may be an electronic bill determined by the first object through a telephone call, a field transaction and the like, or a virtual electronic bill queried by national departments such as a business administration department, a public security department and the like. The false opening of the electronic bill is a fraud behavior that the electronic bill is not opened according to the actual situation, and when tax paying units and individuals make invoices in the commodity transaction process for the purpose of tax evasion or purchasing units need to make invoices in the commodity transaction process, false opening methods are adopted on commodity names, commodity quantity, commodity unit price and amount, and even the electronic bill is falsely opened by utilizing relatively familiar relations.

The service assistance information acquired by the server node may further comprise an associated ticket associated with the first object if the user associated with the electronic ticket (e.g., billing user, personal user, reimbursement user, etc.) belongs to the first object of the virtual electronic ticket. Further, the server node may screen the electronic tickets matching the status change period from the associated tickets, and adjust the ticket status of the screened electronic tickets to the second status. It is understood that if the first object has other illegal activities such as virtual invoicing, the server node may screen the first object for the transfer of electronic tickets to the change-of-state address within the change-of-state period (e.g., one or half month) to invalidate the electronic tickets.

It should be appreciated that the first server node may obtain the business assistance information associated with the electronic ticket in response to the state change operation, and determine the ticket state of the electronic ticket based on the business assistance information. For easy understanding, please refer to fig. 5, which is a schematic view of a scenario for determining a ticket status of an electronic ticket according to an embodiment of the present application.

As shown in fig. 5, the first server node in the embodiment of the present application may be a server node 400 (e.g., a server node of a tax bureau corresponding to the area a), the server node 400 may be the server node 100 corresponding to the above-mentioned fig. 2, and the server node 100 may be a node (e.g., a node 100a) in the block-linked node system shown in the above-mentioned fig. 1. Blockchain node 500 may be a blockchain node in a blockchain network in which the server node is located.

It is to be understood that the blockchain 1 may be a corresponding blockchain link point in the blockchain network in fig. 1, and the blockchain 1 may be an identical blockchain shared by each node in the blockchain network corresponding to the server node 400, and each node may obtain information stored in the blockchain 1. The blockchain 1 includes a block 10a, blocks 10b, …, and a block 10n, where the block 10a may be referred to as a founder block of the blockchain 1. The block 10n may be referred to as the block with the latest stored timestamp in the block chain 1. The blockchain 1 can record the transaction record information of the electronic bill B.

It should be appreciated that the server node 400 may send a transaction query request for the electronic ticket B to the blockchain node 500 in the blockchain network in which the server node 400 is located in response to a state change operation performed by a second object (i.e., the tax authority in the electronic ticket B) with respect to the target area of the display interface to which the electronic ticket B belongs. Wherein the transaction inquiry request can be used to obtain the transaction record information associated with the electronic ticket B in the blockchain 1 as shown in fig. 5. Then, the block link point 500 acquires the block 10n having the latest storage time stamp in the block chain 1, and may continue to search for the block in the block chain 1 according to the block 10n, so that all the transaction record information associated with the electronic ticket B may be acquired. Further, the blockchain node 500 may return the retrieved transaction record information to the server node 400.

Further, the server node 400 may determine the circulation route in the electronic ticket B according to the time stamp of each of the transaction record information. For example, the circulation route of the electronic ticket B may be formed for circulation from an invoicing user having the same regional attribute as the second object (e.g., an invoicing user of the region a) to an individual user. It can be understood that, when the second object is a tax bureau corresponding to the area a and the invoicing user is an invoicing user in the area a, the embodiment of the present application may be understood that the second object and the invoicing user have the same area attribute.

It should be appreciated that the server node 400 may determine the flow route of the electronic ticket B as the service assistance information associated with the electronic ticket B, and may determine the ticket status of the electronic ticket based on the service assistance information. For example, if it is determined that the electronic ticket B is transferred to the first object (for example, a billing user, an individual user, a reimbursement user, etc. in the electronic ticket B) according to the transfer route of the electronic ticket B, it may be determined that the ticket status of the electronic ticket is the first status (i.e., the to-be-voided status). If the electronic bill is determined to be transferred to the state change address according to the transfer route of the electronic bill B, the bill state of the electronic bill can be determined to be the second state (namely, the invalid state). If the electronic bill B is determined to be transferred to the second object (namely, the tax bureau in the electronic bill) according to the transfer route of the electronic bill B, the bill status of the electronic bill B can be determined to be a reimbursed status (namely, an invoiceable status). It should be understood that if the ticket status of the electronic ticket B is the reimbursed status and the ticket information in the electronic ticket B is incorrect, the server node 400 may perform exception handling on the electronic ticket B by using a flushing method, which is not described herein again.

And S102, if the bill state of the electronic bill is a first state and the first server node is determined to have the state change authority, adjusting the bill state of the electronic bill from the first state to a second state.

Specifically, if the ticket status of the electronic ticket is the first status, at this time, the first server node may verify the status change authority of the first server node according to the signature address corresponding to the circulation route of the electronic ticket. When the first server node has the status change right, the first server node can adjust the bill status of the electronic bill from the first status to the second status.

It can be understood that the electronic ticket can be referred to as a first circulation route when the electronic ticket is circulated from the invoicing user with the same regional attribute as the second object to the personal user. The multi-signature address corresponding to the first flow path may be referred to as a first multi-signature address. In other words, the first multi-signed address is determined by both the address of the first server node and the address of the individual user. Wherein the address of the first server node is determined by the first public key of the first server node and the address of the individual user is determined by the public key of the individual user.

It should be appreciated that if the first server node determines that the flow route of the electronic ticket is the first flow route, the first server node may obtain the ticket information in the electronic ticket from the first multi-signed address associated with the electronic ticket. As shown in fig. 5, the server node 400 (first server node) can determine the first flow route as the flow route of the electronic ticket B, and the server node 400 can obtain the ticket information of the electronic ticket B from the multi-signature address associated with the electronic ticket B. Wherein the multiple-signature address (i.e. the first multiple-signature address) of the electronic ticket B can be determined by the address of the server node 400 and the address of the individual user.

At this time, the server node 400 may sign the electronic ticket B based on the private key of the server node 400, to obtain signature information of the electronic ticket B. At this time, the server node 400 may send a signature verification request to a block link point (e.g., the block link node 500) in the block link network where the server node 400 is located based on the signature information, so that the block link point 500 verifies the signature information based on a public key (i.e., the first public key) of the server node 400, and obtains a verification result.

It can be understood that the server node 400 may perform hash calculation on the electronic ticket B, so as to obtain the digest information h of the electronic ticket B, and perform digital signature on the digest information h based on the private key of the server node 400, so as to obtain signature information. The signature information includes the digital signature and the electronic ticket B. Further, the server node 400 may send a signature verification request to the blockchain node 500 in the blockchain network based on the signature information.

At this time, the block chain node 500 may check the digital signature based on the public key of the server node 400 to obtain the digest information H of the electronic ticket B, and perform hash calculation on the electronic ticket B by using the same hash algorithm as that of the server node 400, so as to obtain the digest information H of the electronic ticket B. Further, the blockchain node 500 may compare the digest information H obtained after the signature verification with the digest information H obtained by performing the hash calculation to obtain a signature verification result, and return the signature verification result to the server node 400.

If the summary information H is the same as the summary information H, it indicates that the block link node 500 successfully checks the server node 400, in other words, the server node 400 has the status change authority. If the summary information H is different from the summary information H, it indicates that the signature verification of the block link node 500 to the server node 400 fails, in other words, the server node 400 does not have the status change permission.

It should be understood that if the ticket status of the electronic ticket B is the first status and the server node 400 has the status change authority, the server node 400 may adjust the ticket status of the electronic ticket B from the first status to the second status.

And S103, transferring the electronic bill with the second state to the state change address according to the state change address associated with the state change authority.

Specifically, the first server node may obtain a status change address associated with the status change authority, and transfer the electronic ticket having the second status to the status change address based on a private key of the first server node, so as to invalidate the electronic ticket having the second status.

It should be appreciated that the first server node may also determine this transaction record information of the electronic ticket transferred to the state change address as target transaction record information, and write the target transaction record information on the block link, which may improve the reliability of the target transaction record information due to the non-tamper property of the block link technology.

It is to be understood that, as shown in fig. 5, the blockchain 1 may be a blockchain corresponding to the blockchain network to which the first server node belongs, and the blockchain 1 may be an identical blockchain shared by each node in the blockchain network to which the first server node corresponds, and each node may obtain information stored in the blockchain 1. The blockchain 1 includes a block 10a, blocks 10b, …, and a block 10n, where the block 10a may be referred to as a founder block of the blockchain 1.

It should be appreciated that the first server node (e.g., server node 400) may write the target transaction record information to the blockchain. In other words, the first server node may obtain the chunk 10n with the largest generation timestamp from the blockchain 1. Further, the first server node may generate a target chunk to be written into the chunk chain 1 according to the target transaction record information. At this time, the first server node may broadcast the target block containing the target transaction record information to all blockchain nodes (e.g., consensus nodes for performing consensus processing) in the blockchain network, and when it is determined that all blockchain nodes achieve consensus, may write the target block into the blockchain 1, that is, take the target block as the next block of the block 10 n.

Further, please refer to fig. 6, which is a flowchart illustrating a method for processing ticket data according to an embodiment of the present application. The method may be performed by a first server node in a blockchain network. As shown in fig. 6, the method may include:

s201, responding to the state change operation executed for the electronic bill, acquiring the business auxiliary information associated with the electronic bill, and determining the bill state of the electronic bill according to the business auxiliary information.

S202, if the ticket status of the electronic ticket is the first status and it is determined that the first server node has the status change authority, adjusting the ticket status of the electronic ticket from the first status to the second status.

And S203, transferring the electronic bill with the second state to the state change address according to the state change address associated with the state change authority.

For specific implementation of steps S201 to S203, reference may be made to the description of steps S101 to S103 in the embodiment corresponding to fig. 3, which will not be described herein again.

And S204, if the circulation route in the service auxiliary information is a second circulation route, acquiring the bill information in the electronic bill from a second multiple signature address associated with the electronic bill.

In this embodiment, a flow route formed when the electronic ticket flows from the individual user to the reimbursement user having a different attribute area from the second object may be referred to as a second flow route. The multi-signature address corresponding to the first flow path may be referred to as a first multi-signature address. The second multi-signature address is determined by the address of the second server node corresponding to the tax bureau to which the reimbursement user belongs and the address of the reimbursement user. Wherein the address of the second server node is determined by the second public key of the second server node, and the address of the reimbursement user is determined by the public key of the reimbursement user.

S205, sending a status change notification request for the electronic ticket to the second server node, so that the second server node adjusts the ticket status of the electronic ticket from the first status to a second status when the second server node has the status change authority.

The specific implementation of steps S204 to S205 can refer to the following description of the embodiment corresponding to fig. 7. It should be understood that if the flow route of the electronic ticket determined by the first server node is the second flow route, the first server node can adjust the ticket state of the electronic ticket through the second server node. For easy understanding, please refer to fig. 7, which is a schematic view illustrating a scenario for adjusting a ticket status of an electronic ticket according to an embodiment of the present application.

As shown in fig. 7, in the embodiment of the present application, the first server node may be a server node a (e.g., a server node of a tax bureau corresponding to the area a), the server node a may be the server node 400 corresponding to the area a, the server node 400 may be the server node 100 corresponding to the area b, and the server node 100 may be a node (e.g., the node 100a) in the block-link node system shown in the area b of fig. 1. The second server node in this embodiment may be a server node B (e.g., a server node of a tax bureau corresponding to the area B), the server node B may be a blockchain node in a blockchain network in which the server node a is located, and the server node B may be a node (e.g., the node 100B) in the blockchain-node system shown in fig. 1.

It should be appreciated that the server node a may send a transaction record request for the electronic ticket C to a blockchain node in a blockchain network in which the server node a is located in response to a state change operation of the second object (e.g., the taxing authority of area a) being performed for a target area to which the electronic ticket C belongs. The blockchain link point may return the transaction record information of the electronic ticket C stored in the blockchain corresponding to the blockchain network to the server node a based on the transaction record request.

Further, as shown in fig. 7, the server node a may determine a circulation route of the electronic ticket C according to the transaction record information. For example, the circulation route of the electronic ticket C may be formed when the electronic ticket C is circulated from the invoicing user having the same regional attribute as the second object (e.g., the invoicing user of the region a) to the personal user and then circulated by the personal user to the reimbursement user having a different regional attribute from the second object (e.g., the reimbursement user of the region B). The embodiment of the present application can understand the circulation route of the electronic ticket C as the second circulation route.

It should be understood that the server node a may obtain ticket information for the electronic ticket C from the multiple signed address in the electronic ticket C. The multi-signed address (i.e., the second multi-signed address) of the electronic ticket C may be determined by the address of the server node B and the address of the reimbursement user in the area B. At this time, according to the multiple signature address of the electronic ticket C, the embodiment of the present application may determine that the server node a does not have the status change authority for the electronic ticket C.

Further, the server node a may send a state change notification request for the electronic ticket C to the server node B. Wherein the status change notification request can be used to notify the server node B to perform a status change operation on the electronic ticket. At this time, the server node B determines the ticket status of the electronic ticket C based on the status change request. And when the bill state of the electronic bill C is the first state, verifying the state change authority of the server node B. Further, when the server node B has the status change authority, the ticket status of the electronic ticket C may be adjusted from the first status to the second status, and the electronic ticket C may be transferred to the status change address based on the private key of the server node B.

In this embodiment of the present application, a first server node in a block chain network may quickly determine a ticket state of an electronic ticket and a state change authority of the first server node based on service auxiliary information of the electronic ticket. Wherein the state changing authority is determined by the multiple signature address of the electronic bill. It should be understood that if the multi-signed address contains the address of the first server node, it is understood that the first server node has state change authority. In this case, the first server node having the status change authority may directly adjust the ticket status of the electronic ticket having the first status to the second status, and transfer the electronic ticket having the second status to the status change address, thereby improving the efficiency of exception handling of the electronic ticket. When the first server node does not have the state change authority, the first server node can send a state change notification request to a second server node with the state change authority, so that the second server node can perform exception handling on the electronic bill, and the exception handling efficiency of the electronic bill can be improved.

Further, please refer to fig. 8, which is a schematic structural diagram of a ticket data processing apparatus according to an embodiment of the present application. The ticket data processing apparatus may be a computer program (including program code) running in a computer device, for example, an application software; the bill data processing device can be used for executing corresponding steps in the method provided by the embodiment of the application. As shown in fig. 8, the ticket data processing apparatus 1 may operate in a first server node in a blockchain network, where the first server node may be the server node 100 in the embodiment corresponding to fig. 2. The bill data processing apparatus 1 may include: the system comprises a determination module 10, a first adjustment module 20, a transfer module 30, a second adjustment module 40, a verification module 50, an acquisition module 60, and a sending module 70.

The determining module 10 is configured to obtain service auxiliary information associated with an electronic ticket in response to a status change operation performed on the electronic ticket, and determine a ticket status of the electronic ticket according to the service auxiliary information.

Wherein, the determining module 10 includes: the authentication unit 101, the first acquiring unit 102, the second acquiring unit 103, the first determining unit 104, the first sending unit 105, the second determining unit 106, the third determining unit 107 and the fourth determining unit 108.

The authentication unit 101 is configured to authenticate the first object in response to a state change operation performed by the first object on the display interface to which the electronic ticket belongs.

Wherein, the authentication unit 101 includes: an acquisition sub-unit 1011 and a determination sub-unit 1012.

The acquiring subunit 1011 is configured to respond to a state change operation executed by the first object on the display interface to which the electronic ticket belongs, and acquire an illegal user behavior comparison table from an associated server node associated with the first server node; the illegal user behavior comparison table comprises at least one illegal user; an illegal user is a user which is accumulated in the block chain network and performs the state change operation to reach an operation threshold value;

the determining subunit 1012 is configured to search the first object in the illegal user behavior comparison table, and determine the first object as a legal user when the first object is not searched.

For a specific implementation manner of the acquiring subunit 1011 and the determining subunit 1012, reference may be made to the description of performing authentication on the first object in the embodiment corresponding to fig. 2, and details will not be described here again.

The first obtaining unit 102, configured to obtain service auxiliary information associated with the first object when the authentication is successful;

the second obtaining unit 103 is configured to determine an association relationship between the first object and a user in the electronic ticket according to the service auxiliary information, and obtain transaction record information associated with the electronic ticket according to the association relationship;

the first determining unit 104 is configured to determine a ticket status of the electronic ticket according to the transaction record information.

The first sending unit 105 is configured to send a transaction query request for the electronic ticket to a block link point in the block chain network in response to a state change operation executed by a second object on a display interface to which the electronic ticket belongs; the transaction inquiry request is used for acquiring transaction record information associated with the electronic bill in the block chain network; said second object is subordinate to a tax authority in said electronic ticket;

the second determining unit 106 is configured to determine a circulation route of the electronic ticket according to a timestamp of each transaction record information in the transaction record information;

the third determining unit 107 is configured to determine the circulation route as service auxiliary information associated with the electronic ticket;

the fourth determining unit 108 is configured to determine a ticket status of the electronic ticket according to the service assistance information.

For specific implementation manners of the authentication unit 101, the first obtaining unit 102, the second obtaining unit 103, the first determining unit 104, the first sending unit 105, the second determining unit 106, the third determining unit 107, and the fourth determining unit 108, reference may be made to the description of step S101 in the embodiment corresponding to fig. 4, and details will not be further described here.

The first adjusting module 20 is configured to adjust the ticket status of the electronic ticket from the first status to a second status if the ticket status of the electronic ticket is the first status and it is determined that the first server node has the status change authority;

the transfer module 30 is configured to transfer the electronic ticket having the second status to the status change address according to the status change address associated with the status change authority.

the above-mentioned bill data processing apparatus 1 further includes:

the second adjusting module 40 is configured to screen the electronic bills matching the status change cycle from the associated bills, and adjust the bill status of the screened electronic bills to the second status.

The verification module 50 is configured to verify the status change authority of the first server node according to the multi-signature address corresponding to the forwarding route.

Wherein, the verification module 50 includes: a third acquiring unit 501, a signature unit 502, a second transmitting unit 503 and a fifth determining unit 504.

The third obtaining unit 501, configured to obtain ticket information in the electronic ticket from a first multiple signature address associated with the electronic ticket if the circulation route is a first circulation route; the first circulation route is formed when the electronic bill is circulated from the billing user having the same regional attribute as the second object to the personal user; said first multi-signed address being determined by both an address of said first server node and an address of said individual user; the address of the first server node is determined by a first public key of the first server node;

the signature unit 502 is configured to sign the electronic ticket based on a private key of the first server node to obtain signature information of the electronic ticket;

the second sending unit 503 is configured to send a signature verification request to a block link point in the block chain network based on the signature information, so that the block link point verifies the signature information based on the first public key to obtain a verification result;

the fifth determining unit 504 is configured to obtain the signature verification result returned by the block link point, and determine that the first server node has a status change authority according to the signature verification result.

For specific implementation manners of the third obtaining unit 501, the signature unit 502, the second sending unit 503 and the fifth determining unit 504, reference may be made to the description of verifying the state change permission of the first server node in the embodiment corresponding to fig. 4, and details will not be further described here.

The obtaining module 60 is configured to obtain the ticket information in the electronic ticket from a second multiple signature address associated with the electronic ticket if the forwarding route is a second forwarding route; the second circulation route is formed when the electronic bill is circulated from the individual user to the reimbursement user having the different regional attribute from the second object; the second multiple signature address is determined by the address of the second server node corresponding to the tax bureau to which the reimbursement user belongs and the address of the reimbursement user; the address of the second server node is determined by a second public key of the second server node;

the sending module 70 is configured to send a status change notification request for the electronic ticket to the second server node, so that the second server node adjusts the ticket status of the electronic ticket from the first status to a second status when the second server node has the status change authority.

For specific implementation manners of the determining module 10, the first adjusting module 20, the transferring module 30, the second adjusting module 40, the verifying module 50, the obtaining module 60, and the sending module 70, reference may be made to the description of step S201 to step S205 in the embodiment corresponding to fig. 6, and details will not be further described here. In addition, the beneficial effects of the same method are not described in detail.

Further, please refer to fig. 9, which is a schematic diagram of a node device according to an embodiment of the present application. As shown in fig. 9, the node apparatus 1000 may be the server node 100 in the embodiment corresponding to fig. 2, where the node apparatus 1000 may include: at least one processor 1001, such as a CPU, at least one network interface 1004, a user interface 1003, memory 1005, at least one communication bus 1002. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may include a Display (Display) and a Keyboard (Keyboard), and the network interface 1004 may optionally include a standard wired interface and a wireless interface (e.g., WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk memory. The memory 1005 may optionally also be at least one storage device located remotely from the aforementioned processor 1001. As shown in fig. 9, a memory 1005, which is a kind of computer storage medium, may include therein an operating system, a network communication module, a user interface module, and a device control application program.

In the node apparatus 1000 shown in fig. 9, the network interface 1004 is mainly used for network communication with the user terminal and the block link point; the user interface 1003 is an interface for providing a user with input; and the processor 1001 may be used to invoke a device control application stored in the memory 1005 to implement:

It should be understood that the node device 1000 described in this embodiment of the present application may perform the description of the ticket data processing method in the embodiment corresponding to fig. 4 and fig. 6, and may also perform the description of the ticket data processing apparatus 1 in the embodiment corresponding to fig. 8, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.

Further, here, it is to be noted that: an embodiment of the present application further provides a computer-readable storage medium, and the computer-readable storage medium stores the aforementioned computer program executed by the ticket data processing apparatus 1, and the computer program includes program instructions, and when the processor executes the program instructions, the description of the ticket data processing method in the embodiment corresponding to fig. 4 and fig. 6 can be executed, so that details are not repeated here. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in embodiments of the computer-readable storage medium referred to in the present application, reference is made to the description of embodiments of the method of the present application. As an example, the program instructions may be deployed to be executed on one node apparatus, or on a plurality of node apparatuses located at one site, or on a plurality of node apparatuses distributed at a plurality of sites and interconnected by a communication network, which may constitute a block chain system.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.

The above disclosure is only for the purpose of illustrating the preferred embodiments of the present application and is not to be construed as limiting the scope of the present application, so that the present application is not limited thereto, and all equivalent variations and modifications can be made to the present application.

Claims

1. A ticket data processing method performed by a first server node in a blockchain network, comprising:

responding to state change operation executed aiming at the electronic bill, acquiring business auxiliary information associated with the electronic bill, and determining the bill state of the electronic bill according to the business auxiliary information;

and transferring the electronic bill with the second state to the state change address according to the state change address associated with the state change authority.

2. The method of claim 1, wherein the obtaining business assistance information associated with the electronic ticket in response to a status change operation performed on the electronic ticket, determining a ticket status of the electronic ticket based on the business assistance information comprises:

responding to the state change operation executed by a first object aiming at the display interface to which the electronic bill belongs, and authenticating the first object;

when the authentication is successful, acquiring service auxiliary information associated with the first object;

determining an incidence relation between the first object and a user in the electronic bill according to the business auxiliary information, and acquiring transaction record information associated with the electronic bill according to the incidence relation;

and determining the bill state of the electronic bill according to the transaction record information.

3. The method of claim 2, wherein the authenticating the first object in response to the first object performing the state change operation on the display interface to which the electronic ticket belongs comprises:

responding to state change operation executed by a first object aiming at a display interface to which an electronic bill belongs, and acquiring an illegal user behavior comparison table from an associated server node associated with the first server node; the illegal user behavior comparison table comprises at least one illegal user; an illegal user is a user which is accumulated in the block chain network and performs the state change operation to reach an operation threshold value;

searching the first object in the illegal user behavior comparison table, and determining the first object as a legal user when the first object is not searched.

4. The method of claim 1, wherein the obtaining business assistance information associated with the electronic ticket in response to a status change operation performed on the electronic ticket, determining a ticket status of the electronic ticket based on the business assistance information comprises:

responding to state change operation executed by a second object aiming at a display interface to which an electronic bill belongs, and sending a transaction query request aiming at the electronic bill to a block chain node in the block chain network; the transaction inquiry request is used for acquiring transaction record information associated with the electronic bill in the blockchain network; the second object is subordinate to a tax bureau in the electronic bill;

determining a circulation route of the electronic bill according to the timestamp of each transaction record information in the transaction record information;

determining the circulation route as business assistance information associated with the electronic ticket;

and determining the bill state of the electronic bill according to the service auxiliary information.

5. The method of claim 4, wherein the service assistance information further comprises an association ticket associated with the first object;

the method further comprises the following steps:

screening the electronic bills matched with the state change period from the associated bills, and adjusting the bill states of the screened electronic bills to the second state.

6. The method of claim 4, further comprising:

and verifying the state change authority of the first server node according to the multiple signature addresses corresponding to the circulation route.

7. The method of claim 6, wherein verifying the state change authority of the first server node according to the multi-signature address corresponding to the flow path comprises:

if the circulation route is a first circulation route, acquiring bill information in the electronic bill from a first multiple signature address associated with the electronic bill; the first circulation route is formed when the electronic bill circulates from the invoicing user having the same regional attribute as the second object to the individual user; the first multi-signed address is determined collectively by an address of the first server node and an address of the individual user; the address of the first server node is determined by a first public key of the first server node;

signing the electronic bill based on a private key of the first server node to obtain signature information of the electronic bill;

sending a signature verification request to a block chain node in the block chain network based on the signature information so that the block chain node verifies the signature information based on the first public key to obtain a signature verification result;

and obtaining the label checking result returned by the block link point, and determining that the first server node has the state change permission according to the label checking result.

8. The method of claim 6, further comprising:

if the circulation route is a second circulation route, acquiring bill information in the electronic bill from a second multiple signature address associated with the electronic bill; the second diversion route is formed when the electronic ticket is diverted from the individual user to a reimbursement user having a different regional attribute than the second object; the second multiple signature address is determined by the address of a second server node corresponding to the tax bureau to which the reimbursement user belongs and the address of the reimbursement user; the address of the second server node is determined by a second public key of the second server node;

and sending a state change notification request aiming at the electronic bill to the second server node, so that the second server node adjusts the bill state of the electronic bill from the first state to a second state when the second server node has the state change authority.

9. A ticket data processing apparatus, said apparatus operating in a first server node in a blockchain network, comprising:

the first adjusting module is used for adjusting the bill state of the electronic bill from the first state to a second state if the bill state of the electronic bill is the first state and the first server node is determined to have the state change authority;

10. A node apparatus, comprising: a processor, a memory, and a network interface;

the processor is coupled to a memory for providing data communication functionality, a network interface for storing program code, and the processor is configured to invoke the program code to perform the method of any of claims 1-8.

11. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program comprising program instructions which, when executed by a processor, perform the method according to any one of claims 1-8.