CN110473078B

CN110473078B - Information processing method, device, gateway server and medium in invoice issuing

Info

Publication number: CN110473078B
Application number: CN201910687456.2A
Authority: CN
Inventors: 郭锐; 李茂材; 蔡弋戈; 张建俊; 秦青; 卢吉光; 郑罗海
Original assignee: Shenzhen Zhishuilian Technology Co ltd
Current assignee: Shenzhen Zhishuilian Technology Co ltd
Priority date: 2018-09-07
Filing date: 2018-09-07
Publication date: 2023-04-07
Anticipated expiration: 2038-09-07
Also published as: CN110473078A; CN109360077A; CN109360077B

Abstract

The disclosure provides an information processing method, an information processing device, a gateway server and a medium in invoice issuing. The method comprises the following steps: receiving an invoice issuing request, wherein the invoice issuing request comprises an identifier of an event block issuing the invoice, invoice information and issue event invoice transfer information, which are recorded on a block chain; according to the identification of the event block issuing the invoice, searching the event block issuing the invoice recorded on the block chain; and when the invoice information and the issue event invoice transfer information in the found event block are respectively consistent with the invoice information in the invoice issuing request and the issue event invoice transfer information, sending a response for allowing invoicing. The method and the device can prevent the issuing of false invoices and improve the security of invoicing information processing.

Description

Information processing method, device, gateway server and medium in invoice issuing

The application is a divisional application of an application with the application date of 2018, 9 and 7, and the application number of 201811045443.7, and the invention name of 'information processing method, device, gateway server and medium in invoice reimbursement'.

Technical Field

The present disclosure relates to the field of blockchains, and in particular, to an information processing method and apparatus, a gateway server, and a medium in invoicing.

Background

There are two kinds of reimbursement processes for current invoices. One is the report of the offline and the other is the report of the online. Under the condition of online reimbursement, the staff of the unit buys articles in the unit of the merchant, obtains the electronic invoice of the merchant, prints the electronic invoice and takes the electronic invoice to the unit for reimbursement. If the employee modifies the electronic invoice and prints the invoice before printing, the reimbursement unit cannot verify the electronic invoice, and a large amount of false invoice reimbursement is caused. Under the condition of online reimbursement, the staff can also modify the electronic invoice on a computer and then online transmit the electronic invoice to financial equipment of a unit for reimbursement to cause reimbursement of the virtual invoice. The existing invoice reimbursement mechanism cannot monitor whether the reimbursed invoice is consistent with the invoice at the time of issuing.

In addition, there may be instances of duplicate reimbursements. Under the condition of online reimbursement, an employee can correct the new head after printing the electronic invoice, reimbursement is respectively carried out on a plurality of units, and the plurality of units are difficult to verify. Under the condition of online reimbursement, an advanced technical means is also provided to modify the head-up of the electronic invoice in a computer, so that reimbursement is respectively carried out in different units. Existing invoice reimbursement mechanisms also lack monitoring for repeat reimbursements.

Disclosure of Invention

An object of the present disclosure is to provide an information processing technique in invoice issuing, which can prevent issuing of false invoices, that is, invoices cannot be issued when the issued invoices are inconsistent with invoices at the time of issuance, and improve security of invoice issuing information processing.

According to an aspect of the disclosed embodiment, an information processing method in invoicing is disclosed, which comprises the following steps:

receiving an invoice issuing request, wherein the invoice issuing request comprises identification of an event block issuing the invoice, invoice information and issue event invoice transfer information, which are recorded on a block chain;

according to the identification of the event block issuing the invoice, searching the event block issuing the invoice recorded on the block chain;

and when the invoice information and the issue event invoice transfer information in the found event block are respectively consistent with the invoice information in the invoice issuing request and the issue event invoice transfer information, sending a response for allowing invoicing.

According to an aspect of the embodiments of the present disclosure, an information processing apparatus in invoicing is disclosed, which includes:

a second receiving unit, configured to receive an invoice issuing request, where the invoice issuing request includes an identifier of an event block issuing the invoice, invoice information, and issue event invoice transfer information, which are recorded on a block chain;

the second searching unit is used for searching the event block issuing the invoice recorded on the block chain according to the identifier of the event block issuing the invoice;

and the second sending unit is used for sending a response of allowing invoicing when the invoice information and the issue event invoice transfer information in the found event block are respectively consistent with the invoice information in the invoicing request and the issue event invoice transfer information.

According to an aspect of the disclosed embodiments, a blockchain gateway server is disclosed, which includes: a memory storing computer readable instructions; a processor reading computer readable instructions stored by the memory to perform the above described method.

According to an aspect of embodiments of the present disclosure, a computer program medium is disclosed, having computer readable instructions stored thereon, which, when executed by a processor of a computer, cause the computer to perform the method as described above.

In the embodiment of the disclosure, the invoice information and the invoice issue event invoice transfer information when the invoice is issued are recorded on the block chain as at least one part of the block main body of the event block issuing the invoice, and an identifier is generated for the block. At the time of invoice issuance, invoice information is provided, as well as invoice issue event invoice diversion information. Due to the consensus mechanism of the blockchain, invoice information written on the blockchain when an invoice is issued and invoice transfer information of an invoice issue event cannot be falsified, and all nodes on the blockchain can be seen, so that whether the invoice is a false invoice can be judged by comparing invoice information provided when the invoice is issued and the invoice transfer information of the invoice issue event invoice with invoice information recorded on the blockchain when the invoice is issued and the invoice transfer information of the invoice issue event invoice, and the false invoice is avoided from being issued, and the safety is improved.

Additional features and advantages of the disclosure will be set forth in the detailed description which follows, or in part will be obvious from the description, or may be learned by practice of the disclosure.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The above and other objects, features and advantages of the present disclosure will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings.

Fig. 1A to 1O are schematic diagrams illustrating various interfaces involved in issuing an invoice to invoice reimbursement when an information processing method in invoice reimbursement is applied to an online reimbursement application scenario according to an embodiment of the present disclosure.

Fig. 2A to 2G show schematic diagrams of various interfaces involved when an information processing method in invoice reimbursement applies an online reimbursement application scenario according to one embodiment of the present disclosure.

FIG. 3A illustrates an architectural diagram to which the information processing method in invoice reimbursement is applied, according to one embodiment of the present disclosure.

FIG. 3B illustrates a diagram of a complete flow process for an invoice in the architecture shown in FIG. 3A.

FIG. 4 shows a flow diagram of a method of information processing in invoice reimbursement according to one embodiment of the present disclosure.

FIG. 5 shows a flow diagram of a method of information processing in invoice reimbursement according to one embodiment of the present disclosure.

FIG. 6 shows a detailed flowchart of step 450 in FIG. 5, according to one embodiment of the present disclosure.

FIG. 7 shows a detailed flowchart of step 430 in FIG. 4 according to one embodiment of the present disclosure.

FIG. 8 shows a detailed flowchart of step 4301 in FIG. 7 according to one embodiment of the present disclosure.

FIG. 9 shows a flow diagram of a method of information processing in invoice reimbursement according to one embodiment of the present disclosure.

FIG. 10 shows a flow diagram of a method of information processing in invoice reimbursement according to one embodiment of the present disclosure.

FIG. 11 shows a flow diagram of a method of information processing in invoice reimbursement according to one embodiment of the present disclosure.

FIG. 12 shows a flow diagram of a method of information processing in invoice reimbursement according to one embodiment of the present disclosure.

FIG. 13A shows an interaction flow diagram for an employee terminal, reimbursement unit terminal, blockchain gateway server with online reimbursement according to one embodiment of the present disclosure.

Fig. 13B shows an interaction flow diagram of an employee terminal, a reimbursement unit terminal, a blockchain gateway server in the case of online reimbursement according to one embodiment of the present disclosure.

FIG. 14 shows a block diagram of an information processing device in invoice reimbursement according to one embodiment of the present disclosure.

Fig. 15 shows a hardware block diagram of a blockchain gateway server according to one embodiment of the present disclosure.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these example embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus their repetitive description will be omitted.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more example embodiments. In the following description, numerous specific details are provided to give a thorough understanding of example embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the embodiments of the present disclosure can be practiced without one or more of the specific details, or with other methods, components, steps, etc. In other instances, well-known structures, methods, implementations, or operations are not shown or described in detail to avoid obscuring aspects of the disclosure.

Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

The architecture and overall flow for the embodiments of the present disclosure will be described with reference to fig. 3A-3B.

FIG. 3A illustrates an architecture to which embodiments of the present disclosure apply. The architecture includes a blockchain invoice management system 4, an invoice issuing terminal 301 located at the business organization 3, an invoicing terminal 201 located at an invoicing unit (claiming invoice unit) 2, an invoice reimbursement unit terminal 101 located at an invoice reimbursement unit 1, and an employee terminal 102. The blockchain invoice management system 4 includes a blockchain gateway server 401, a blockchain server 402, and a bank system server 404. There are typically multiple blockchain servers 402 in blockchain invoice management system 4. The plurality of blockchain servers 402 manage electronic invoices of respective users (including the invoice issuing terminal 301, the billing terminal 201, the reimbursement unit terminal 101 and the employee terminal 102) based on a blockchain technique. Blockchain gateway server 401 is used to provide access services between users and blockchain invoice management system 4, and may also serve as a billing node in this implementation environment. The banking system server 404 is used to handle issues such as bank payments involved in invoices.

The invoice issuing terminal 301, the invoicing terminal 201, the reimbursement unit terminal 101, and the employee terminal 102 may be dedicated terminals, or may be general-purpose terminals with applications installed thereon, such as a desktop computer, a mobile phone, a PDA, a notebook computer, and the like. Each of blockchain gateway server 401, blockchain server 402, and bank system server 404 may be implemented by a single computer or a portion thereof (as a virtual machine), may be implemented by multiple networked computers, or may be implemented by a combination of portions of multiple networked computers. For example, it may be in the form of a virtual machine cluster, i.e., a part of each of the plurality of physical machines is divided into virtual machines, and the virtual machines collectively perform their functions. In a cloud environment, it may also be implemented jointly by multiple distributed computing devices in the cloud environment.

Each user of the blockchain invoice management system 4 (including the invoice issuing terminal 301, the invoicing terminal 201, the reimbursement unit terminal 101 and the employee terminal 102) and the blockchain invoice management system 4 may be a blockchain node, that is, the invoice information recorded by all the upper blockchain records is recorded. The blockchain invoice management system 4 and each user of the blockchain invoice management system 4 can store the same blockchain, the blockchain is composed of a plurality of blocks, each block stores different information, and the blocks on the blockchain are stored according to a time sequence. For each device that stores the same blockchain, it is called a blockchain node. In an embodiment of the present invention, each tile may record information related to an event in the invoice stream. For example, for an invoice issuing event, a block is recorded on a blockchain, and information related to the invoice issuing event is recorded, wherein the information comprises invoice information and invoice transfer information of the invoice issuing event; for the billing event, recording a block on a block chain, wherein the information related to the billing event is recorded, and the information comprises invoice information and invoice transfer information of the billing event; for the invoice reimbursement event, a block is recorded on the block chain, and information related to the invoice reimbursement event is recorded, wherein the information comprises invoice information and invoice transfer information of the invoice reimbursement event. The blockchain invoice management system 4 and the users of the blockchain invoice management system 4 can respectively store the same blockchain, so that a joint supervision effect is achieved, and any information recorded on the blockchain cannot be tampered. Therefore, in the embodiment of the disclosure, the characteristic that the data on the blockchain cannot be tampered can be utilized, in the invoice reimbursement link, the invoice information and the invoice transfer information of the invoice reimbursement request are compared with the invoice information and the invoice transfer information of the corresponding invoicing event recorded in the invoicing link, reimbursement is allowed only if the comparison is consistent, and false invoice reimbursement is prevented.

As shown in fig. 3B, in the embodiment of the present disclosure, events such as issuance, issue, reimbursement, and the like of an invoice are recorded on each blockchain node by the blockchain gateway server 401, so that other nodes in the implementation environment can share the invoice information, and thus each node can provide a consistency certification for the invoice information, and the security of the invoice information is improved. The disclosed embodiment issues the invoice as an asset, and each transfer of the asset is considered as an event, which is recorded to the blockchain link point by the blockchain gateway server 401. Specifically, the invoice issuing terminal 301 issues an invoice to the invoicing terminal 201, and simultaneously records an event of issuing the invoice to each blockchain node through the blockchain gateway server 401. The billing terminal 201 issues invoices to the staff of the reimbursement entity, so that the electronic invoices are transferred to the staff terminal 102 at the time of billing, and billing events are recorded on the blockchain link points by the blockchain gateway server 401. When the employee takes the invoice to the reimbursement unit terminal 101 for reimbursement, the reimbursement unit terminal 101 reports to the blockchain gateway server 401, the blockchain gateway server 401 retrieves the invoicing event recorded on the blockchain when the invoice is invoiced, the reimbursement invoice information is checked with the information in the invoicing event, and if the invoice is correct, the invoice is not a false invoice. Meanwhile, the blockchain gateway server 401 may also check the reimbursement person of the invoice with the person to which the invoice recorded at present is transferred, and if no error exists, it indicates that the invoice is not reimbursed. In the event that the invoice is not a false invoice and is not a duplicate reimbursement, the invoice is allowed to reimburse. After reimbursement, the invoice reimbursement unit terminal 101 records the invoice reimbursement event to the blockchain link point through the blockchain gateway server 401.

A brief process of the information processing method in invoice reimbursement applied to the online reimbursement application scenario and the offline reimbursement application scenario according to an embodiment of the present disclosure will be described below with reference to fig. 1A to 1O and fig. 2A to 2G. From the description of these figures, one can see the one completion process of all links from issuance to reimbursement of an invoice.

The unit (including enterprise, institution, national institution, social team) needing the invoice first claims the invoice in the commercial institution. Then, the business organization issues an invoice to the unit, and an interface displayed on an invoice issuing system of the business organization when the invoice is issued is shown in fig. 1A. On the interface shown in fig. 1A, the staff of the industrial and commercial institution needs to fill out the invoice claiming unit, the taxpayer identification number of the claiming invoice unit, the invoice code to be issued by the claiming invoice unit, the invoice number, the invoice usage rule, and the issuing institution. The invoice code and the invoice number are combined to form an invoice identifier which is a mark for uniquely distinguishing the invoice from other invoices. The invoice code is a mark that uniquely identifies the batch from which the invoice was issued. The invoice codes of a batch of invoices issued for the claiming invoice entity are the same. By the invoice code, the batches issued by the invoice can be distinguished. The invoice number is a unique identifier that identifies a particular invoice in a batch. The invoice numbers of different invoices are different in the same batch. The invoice can be uniquely identified by adding the invoice number to the invoice code. When issuing, the issuing authority generally does not issue only one invoice to the claiming invoice entity, and therefore, the invoice number often fills in a range. Usage rules are rules that an invoice must follow when it is issued. For example, it can be stated that the filling amount of each invoice can not exceed 10 ten thousand yuan, the total amount of each invoice issued per week can not exceed 100 ten thousand yuan, the invoice new line must be a Shenzhen city subordinate unit, and the like. After the business organ sets the rules for the invoice claiming unit, when the invoice claiming unit issues the invoice, the system can automatically verify whether the invoice conforms to the use rules. For example, checking whether the filling amount of the invoice does not exceed 10 ten thousand yuan, calculating the total amount of the invoice issued by the system in the week, auditing whether the total amount does not exceed 100 ten thousand yuan after the invoice is issued, whether the new head of the invoice is a subordinate unit of Shenzhen city, and the like. After the completion of the filling, the staff of the industrial and commercial department points the 'confirmation' button, the invoice issuing system generates electronic invoices issued to the invoice applying unit according to the information filled on the interface, and the electronic invoices are automatically transmitted to the invoice issuing system of the invoice applying unit. Meanwhile, the invoice issuing system takes the invoice issuing behavior as an invoice issuing event, records the invoice issuing behavior on the block chain as an event block for issuing the invoice, and records the invoice information filled in as shown in fig. 1A and invoice transfer information of the invoice issuing event in the block. The invoice transfer information comprises the transfer-out party information, the transfer-in party information and the transfer time of the invoice. In the issue invoice event, the roll-out party is a work and commerce institution, such as "Shenzhen city work and commerce bureau" shown in FIG. 1A, the roll-in party is a claim invoice unit, such as "Shenzhen city Lvye Limited liability company" shown in FIG. 1A, and the transfer time is the time for starting to issue the invoice after clicking the "confirm" button of FIG. 1A, and the time is automatically recorded by the invoice issuing system.

At the time of invoicing, an interface as shown in FIG. 1B is displayed on the invoicing system of the billing unit. The invoicer, the taxpayer identification number, the invoice code, the invoice number, the usage rule, the address, the telephone, the issuer and the account number on the left side interface are automatically filled by the invoice issuing system, wherein the invoicer numbers which are not issued can be sequentially selected from the range of the invoice numbers issued by the invoicer shown in fig. 1A and automatically filled on the left side interface, for example, the invoicer numbers are selected from small to large. The information in the right side interface is filled in when the employee in charge of invoicing of the invoicing unit is required to invoice, and mainly comprises an invoice head-up name, an invoice head-up taxpayer identification number, a receiver telephone, an address, a telephone, an account number, an amount, a purpose and the like. After completion of the filling, the employee of the billing entity points the "confirm" button. The invoice issuing system issues electronic invoices issued by the issuing entity according to information filled in on the interface, and the electronic invoices are transferred to a card package of a retriever (namely, an employee of the invoice reimbursement entity) in a mode of WeChat scanning and the like which is described below. Meanwhile, the invoice issuing system takes the current invoicing behavior as an invoicing event and records the invoicing event on the block chain as an invoicing event block, and the invoice information filled in as shown in the figure 1B and the invoicing event invoice transfer information are recorded in the block. The invoice transfer information comprises the transfer-out party information, the transfer-in party information and the transfer time of the invoice. In the event of invoicing, the transferring party is an invoicing unit, such as "Shenzhen Luye Limited liability company" shown in FIG. 1B, the transferring party is an employee, such as "Zhang Xin" shown in FIG. 1B, and the transfer time is the time for starting invoicing after clicking the "confirm" button of FIG. 1B, and the time is automatically recorded by the invoicing system.

In FIG. 1B, after the employee of the billing entity clicks the "OK" button, the two-dimensional code shown in FIG. 1C appears on the interface. After the employee scans the two-dimensional code with his/her mobile phone, i.e., the employee terminal 102, the electronic invoice is automatically stored in the employee's mobile phone, for example, in a WeChat card package stored in the mobile phone.

After the employee scans the two-dimensional code in fig. 1C with the mobile phone, an indication "you have successfully scanned the two-dimensional code, and the electronic invoice has stored a WeChat card bag" appears on the interface in fig. 1D.

After seeing the interface of fig. 1D, the employee opens the WeChat, touches the "me" option in the lower right corner, and appears options such as "wallet", "collection", "album", "card package" on the screen, as shown in fig. 1E.

The employee selects the "card package" option shown in FIG. 1E and the interface shown in FIG. 1F appears. The interface lists the contents of the employee's card package, including "card", "friends' coupon", "my ticket", etc. The electronic invoice is in "my tickets".

The employee selects "my ticket" on the interface shown in fig. 1F, and all tickets stored on the employee's mobile phone are displayed on the screen, wherein three invoices are distinguished by an invoice identifier, and the invoice identifier is formed by an invoice code — an invoice number, as shown in fig. 1G.

The employee selects an invoice displayed on the interface of FIG. 1G and the interface appears on the screen as shown in FIG. 1H. The interface lists the action options that can be performed on the invoice, including "browse", "print", "send to". The "print" option is typically used in the case of printing an electronic invoice as a paper line claim. The "send to" option is generally used in the case of sending an electronic invoice to a reimbursement unit terminal for reimbursement of the electronic invoice. The "browse" option is typically used to view the invoice before printing it into a paper or sending it to a reimbursement unit.

The employee inputs the registration ID of the reimbursement unit terminal on the interface shown in fig. 1H, and transmits the electronic invoice to the reimbursement unit terminal for reimbursement. At this time, an interface as shown in fig. 1I is automatically generated on the screen of the reimbursement unit terminal. The information displayed by the interface comprises invoice information and invoice transfer information of the invoicing event. Wherein the invoice information is automatically generated based on the information on the electronic invoice delivered to the reimbursement entity terminal, which is substantially the same as the information in fig. 1B. The invoice transfer information of the invoicing event is automatically generated by an invoice reimbursement system of a reimbursement unit terminal. It includes the information of the roll-out party, the information of the roll-in party, the phone of the roll-in party, the transfer time (not shown), etc., wherein the information of the roll-out party is generated according to the information of the drawer in the invoice information, and is consistent with the drawer information, for example, the 'Shenzhen City LvYenLimited liability company' in FIG. 1B; the transfer-in party information is generated according to the information of the retriever in the invoice information, and is consistent with the information of the retriever, such as 'Zhanxin' in FIG. 1B; the incoming call is generated according to the recipient's telephone in the invoice information, e.g. "135 Twai 355" in fig. 1B.

The financial staff of the reimbursement organization reviews the interface in fig. 1I, and after the receipt is deemed to be correct, the financial staff needs to check whether the invoice is false, whether the invoice is reimbursed, and the like, but the reimbursement organization cannot perform such check, and needs to send a request to the blockchain invoice management system 4, so that the blockchain invoice management system 4 performs such check, and then returns the check result to the reimbursement organization terminal, so that the financial staff of the reimbursement organization determines whether the invoice should be reimbursed. At this time, the financial staff of the reimbursement unit selects the "send invoice reimbursement request" button of the interface of fig. 1I, and the reimbursement unit terminal sends an invoice reimbursement request including the information shown in fig. 1I to the blockchain invoice management system 4. The block chain invoice management system 4 starts to audit the invoice reimbursement request and determines whether reimbursement is allowed.

After the reimburser for the reimbursement entity selects "send invoice reimbursement request" of FIG. 1I, the interface of FIG. 1J appears. In this interface, "platform is auditing your invoice reimbursement request, please wait patiently" is displayed.

When the block chain invoice management system 4 audits the invoice, the invoice information in the event block generated when the invoice is invoiced, which is stored in the block chain, and the invoicing event invoice transfer information are searched. If the invoice information in the invoice reimbursement request, the invoicing event invoice transfer information and the invoice information in the event block generated when the invoice of the invoice stored in the blockchain is invoiced, the invoice is a falsified or false invoice. At this time, an interface as shown in fig. 1K is displayed, and "your invoice information does not match the registered invoice information, and therefore there is tampering and the audit is not passed" is displayed.

If the invoice information in the invoice reimbursement request, the invoicing event invoice transfer information is consistent with the invoice information in the event block generated when the invoice of the invoice is stored in the blockchain, the invoicing event invoice transfer information, the invoice is not a tampered or false invoice. In one embodiment of the present disclosure, it is also verified whether the invoice is a reimbursed invoice. Since the invoice is used as an asset and the ownership of the invoice is transferred to the reimbursement unit from the employee after the invoice is reimbursed and the online reimbursement is completed, if the blockchain invoice management system 4 checks that the current invoice owner is not the reimbursed employee, it is likely that the invoice has been reimbursed once and the transfer of ownership is completed, and the invoice is not allowed to be reimbursed. For the case of an offline reimbursement, the reimbursement entity may query the blockchain invoice management system 4 as to whether the invoice should be reimbursed, but since the reimbursement entity is not online after reimbursement, it does not care or want to go to the blockchain invoice management system 4 to effect a transfer of ownership of the invoice. Therefore, in the case of online reimbursement, in the embodiment of the present disclosure, a locking state is set for the invoice in a process of printing the electronic invoice for reimbursement. In the locked state, reimbursement is only allowed once. If the invoice is in a locked state and requested for reimbursement for the second time, in this case, reimbursement of the invoice is not allowed. In this way, duplicate reimbursements are prevented. Thus, the risk of invoice reimbursement is greatly reduced. FIG. 1L shows an interface showing "your invoice information has been reimbursed, so the audit has failed".

Since the embodiment of the disclosure prevents reimbursement of false invoices and prevents reimbursement, if it is checked that there is no reimbursement of false invoices or reimbursement is not involved, reimbursement is allowed, and at this time, an interface shown in fig. 1M is displayed to show "whether the platform has audited to pass your invoice reimbursement request and needs to complete invoice transfer".

The financial staff of the reimbursement organization selects "yes" at the interface shown in FIG. 1M, at which point a confirmation page appears for invoice information and reimbursement event invoice transfer information, as in FIG. 1N. The invoice information in the interface is automatically generated according to the information in the electronic invoice sent by the staff to the reimbursement agency terminal, which basically corresponds to the invoice information in the interface shown in fig. 1I. The reimbursement event invoice transfer information in the interface comprises transfer-out party information, transfer-in party information, transfer-out party telephone and the like. The forwarding party information is generated according to the information of the retriever in the invoice information, the forwarding party information is generated according to the top name of the invoice in the invoice information, and the forwarding party telephone is generated according to the telephone of the retriever in the invoice information.

After checking that the information is correct, the financial staff of the reimbursement organization selects the "send reimbursement invoice transfer request" button in fig. 1N, and sends a reimbursement invoice transfer request to the blockchain invoice management system 4. The reimbursement invoice transfer request comprises invoice information and reimbursement event invoice transfer information. The block chain invoice management system 4 records the invoice information and reimbursement event invoice transfer information as event blocks for reimbursement of the invoices on the block chain. In this way, a transfer of ownership of the invoice from the employee to the reimbursement entity is achieved, and an interface to the financers of the reimbursement entity that "the invoice transfer has been successfully completed" is displayed, as shown in FIG. 1O.

Fig. 2A to 2G illustrate schematic diagrams of various interfaces involved when an information processing method in invoice reimbursement applies an online reimbursement application scenario according to one embodiment of the present disclosure.

If the employee selects "print" for online reimbursement on the invoice processing selection interface shown in FIG. 1H, the employee's terminal displays "please connect the data line to the printer for printing" at this time, as shown in FIG. 2A. Meanwhile, an invoice offline printing request is sent to the blockchain invoice management system 4, and the blockchain invoice management system 4 records the invoice as a locked state. The locking state is characterized in that the invoice in the locking state is only allowed to be reimbursed once, or the invoice reimbursement request is sent to the blockchain invoice management system 4 once by the terminal of a reimbursement unit, and reimbursement is not performed more than once, so that the aim of avoiding repeated reimbursement under the condition of online reimbursement is fulfilled.

Assuming that the employee has connected the terminal to the printer through the connection line, "connected, start printing" is selected on the interface shown in fig. 2A, at which time the printer starts printing the electronic invoice. The printed invoice is provided with a two-dimensional code which represents a block main body abstract value of an event block for issuing the invoice recorded on a block chain, wherein the abstract value is equivalent to the identifier of the event block for issuing the invoice, and the event block for issuing the invoice is unique, and the event block for issuing the invoice can be found through the two-dimensional code.

When the reimbursement is carried out on line, the employee takes the printed electronic invoice to a financial staff of the reimbursement unit. The financial staff selects "reimbursement" in the invoice reimbursement system, and the interface shown in fig. 2B appears to show "please scan the two-dimensional code on the invoice to be reimbursed with the connected scanner". At this time, the financial staff scans the two-dimensional code by using a scanner and identifies the block main body abstract value of the event block for issuing the invoice.

Then, in the interface of fig. 2C, the financial staff of the reimbursement entity fills in invoice information, invoice transfer information for the invoicing event. The invoice information is filled according to the information on the printed invoice, the roll-out person information of the invoice transfer information of the invoicing event is filled according to the invoicer information in the printed invoice, the roll-in party information is filled according to the retriever information in the printed invoice, and the roll-in party telephone is filled according to the retriever telephone in the printed invoice. The fiscal person then selects "send invoice reimbursement request" on the interface, sends an invoice reimbursement request to blockchain invoice management system 4, the invoice reimbursement request including the block body digest value obtained by scanning the two-dimensional code, invoice information filled on the interface of fig. 2C, and invoice transfer information for the invoicing event.

Then, the reimbursement unit terminal displays an interface as shown in fig. 2D, showing "the platform is auditing your invoice reimbursement request, please wait patiently".

If the blockchain invoice management system 4 finds that the invoice information and the invoicing event invoice transfer information in the invoice reimbursement request are inconsistent with the invoice information and the invoicing event invoice transfer information in the event block generated when the invoice stored in the blockchain is invoiced, the invoice is a tampered or false invoice. At this time, an interface as shown in fig. 2E is displayed, and "your invoice information does not match the registered invoice information, and therefore there is tampering and the audit is not passed" is displayed.

If the invoice information in the invoice reimbursement request, the invoicing event invoice transfer information is consistent with the invoice information in the event block generated when the invoice of the invoice is stored in the blockchain, the invoicing event invoice transfer information, the invoice is not a tampered or false invoice. In one embodiment of the present disclosure, it is also verified whether the invoice is a reimbursed invoice. The method of verifying reimbursement may include determining whether the current owner of the invoice is the employee (the taker of the invoice) and determining whether the invoice is in an unlocked state or is in a locked state but first requests reimbursement. If the current owner of the invoice is the employee, and the invoice is in an unlocked state or is in a locked state but first requests reimbursement, then reimbursement is not repeated. If the current owner of the invoice is not the employee, or the invoice is in a locked state and not the first time a reimbursement is requested, then a repeat reimbursement is displayed showing an interface of "your invoice information has been reimbursed and therefore the audit has failed," as shown in FIG. 2F.

If neither a false invoice reimbursement nor a repeat reimbursement is detected, reimbursement is permitted, at which point the interface shown in FIG. 2G is displayed showing "the platform has audited through your invoice reimbursement request".

As shown in fig. 4, according to one embodiment of the present disclosure, an information processing method in invoice reimbursement is provided. The method is performed by a blockchain gateway server (e.g., blockchain gateway server 401 in fig. 3A). The method comprises the following steps:

step 410, receiving an invoice reimbursement request, wherein the invoice reimbursement request comprises an identifier of an event block for issuing the invoice, invoice information and invoice transfer information of an event for issuing the invoice, which are recorded on a block chain;

step 420, searching the event block for issuing the invoice recorded on the block chain according to the identifier of the event block for issuing the invoice;

and 430, when the invoice information and the invoice transfer information of the invoicing event in the found event block are respectively consistent with the invoice information in the invoice reimbursement request and the invoice transfer information of the invoicing event, sending a response for allowing the invoice reimbursement.

These steps are described in detail below, respectively.

In step 410, an invoice reimbursement request is received, the invoice reimbursement request including an identification of an event block recorded on a block chain from which the invoice was issued, invoice information, invoicing event invoice transfer information.

The invoice reimbursement request is a request sent by the invoice reimbursement unit terminal 101 to the blockchain gateway server 401 to verify whether the invoice is reimburseable.

In the application scenario of invoice online reimbursement, an invoice reimbursement request is sent in response to the financial staff of the reimbursement entity selecting "send invoice reimbursement request" on the interface of FIG. 1I.

The identification of the event block is a unique symbol for distinguishing the event block, and the identification of different event blocks is different.

In one embodiment, the identification of the event block is a digest value obtained by performing a digest operation on the block body of the event block. The identifier of the event block for issuing the invoice is a summary value obtained by performing summary operation on the block main body of the event block for issuing the invoice. The abstract values obtained by abstract operation of different character strings are different, so the abstract values can be used as the identifiers of the event blocks.

In another embodiment, the identification of the event block is a digest value obtained by performing a digest operation on the event block, i.e., a digest value obtained by performing a digest operation on the entire event block including the block header and the block body. The identifier of the event block for issuing the invoice is a summary value obtained by performing summary operation on the event block (including a block main body and a block head) for issuing the invoice.

In another embodiment, the identification of the event block is the height of the event block on the blockchain. The identification of the event block from which the invoice was issued is the height of the event block from which the invoice was issued on the blockchain. It is understood that the identification of the event block may also be obtained in other ways, and the embodiment of the present invention is not limited thereto.

The invoice information is the invoice information in fig. 1I, and the invoicing event invoice transfer information is the invoicing event invoice transfer information as in fig. 1I. The invoice information is read from the electronic invoice forwarded from the employee terminal 102 to the invoice reimbursement entity terminal 101 and verified by the fiscal staff of the invoice reimbursement entity. The invoicing terminal 201 places an electronic invoice, which contains invoice information, in the card package of the employee terminal 102. If the employee does not tamper with the invoice but forwards the invoice directly to the invoice reimbursement entity terminal 101, the invoice information can be read directly from the electronic invoice. The invoice transfer information of the invoicing event is automatically generated by an invoice reimbursement system of a reimbursement unit terminal. The invoice information processing method comprises the steps of transferring-out party information, transferring-in party telephone and the like, wherein the transferring-out party information is generated according to the information of the drawer in the invoice information and is consistent with the information of the drawer; the transfer-in party information is generated according to the information of the retriever in the invoice information and is consistent with the information of the retriever; the transfer party phone is generated according to the call of the retriever in the invoice information. The block body digest value of the event block issuing the invoice is generated by using a digest algorithm (e.g., hash algorithm, etc.) when the invoicing terminal 201 issues the invoice to the employee of the reimbursement entity, and is an identifier representing the event block, which is different from other event blocks. The block body abstract value can be directly printed on the electronic invoice, so that the reimbursement unit terminal 101 can directly read the block body abstract value and place the block body abstract value in the invoice reimbursement request. The block body abstract value can also be converted into a two-dimensional code to be printed on the electronic invoice. In this way, the electronic invoice is transmitted to the reimbursement unit terminal 101, the reimbursement unit terminal 101 automatically identifies the two-dimensional code on the electronic invoice, places the block body digest value represented by the two-dimensional code in the invoice reimbursement request, and transmits the invoice reimbursement request to the block chain gateway server 401.

In the invoice line reimbursement application scenario, the invoice reimbursement request is sent in response to the financial staff of the reimbursement unit selecting "send invoice reimbursement request" on the interface of FIG. 2C. The invoice information and invoice transfer information of the invoicing event are information filled by the financial staff according to the printed invoice information in the figure 2C. The invoice transfer information of the invoicing event comprises transfer party information, a transfer party telephone and the like, wherein the transfer party information is generated according to the information of the invoicers in the printed invoices and is consistent with the information of the invoicers; the transfer-in party information is generated according to the information of the retriever in the printed invoice and is consistent with the information of the retriever; the transfer-to party phone is generated according to the call of the retriever in the printed invoice. The block body digest value of the event block issuing the invoice is generated by using a digest algorithm (e.g., hash algorithm, etc.) when the invoicing terminal 201 issues the invoice to the employee of the reimbursement entity, and is an identifier representing the event block, which is different from other event blocks. The block body abstract value is also converted into a two-dimensional code to be printed on the electronic invoice. Thus, when the employee prints the electronic invoice, the two-dimensional code is printed on the printed invoice. As shown in fig. 2B, after the financial staff of the reimbursement unit scans the two-dimensional code on the printed invoice with the scanner, the reimbursement unit terminal 101 automatically identifies the two-dimensional code on the electronic invoice, places the block body digest value represented by the two-dimensional code in the invoice reimbursement request, and sends the invoice reimbursement request to the block chain gateway server 401.

In step 420, according to the identifier of the event block issuing the invoice, the event block issuing the invoice recorded on the block chain is searched.

As described above, the identifier of the event block for issuing the invoice is a symbol that distinguishes the event block for issuing the invoice from other event blocks, and therefore, the blockchain gateway server 401 can find the event block for issuing the invoice recorded on the blockchain according to the identifier.

Specifically, when the identifier of the event block for issuing the invoice is the block main body summary value of the event block for issuing the invoice, the block main body summary value of the event block for issuing the invoice is generated by performing summary operation on a block main body including invoice information and invoice transfer information of the invoice issuing event. An example of such a digest operation is a hash operation. And in the link of issuing the invoice, adding an event block for issuing the invoice on the block chain. The event block includes a block header and a block body. And recording the invoice information and invoice transfer information of the invoicing event on a block chain as at least one part of a block main body of the event block for issuing the invoice. The tile body may also include other parts such as reimbursement terminal signature information, remark information when the tile is generated, etc. In one embodiment, the calculated digest value of the block body of the invoiced event block and the digest value of the last block preceding the block chain where the invoiced event block is not recorded are at least part of the block header of the invoiced event block. The block header may also include other parts such as parity codes and the like. In another embodiment, the calculated digest value of the block body of the invoiced event block and the digest value of the block body of the last block before the invoiced event block on the block chain are at least part of the block header of the invoiced event block. In another embodiment, the calculated summary value of the invoiced event block and the summary value of the last block before the invoiced event block on the block chain is not recorded are at least part of the block header of the invoiced event block. In another embodiment, the calculated summary value of the invoiced event block and the summary value of the block body of the last block before the invoiced event block on the block chain is not recorded are at least part of the block header of the invoiced event block.

Since the events of all invoices on a blockchain are recorded in time sequence, and the events of a plurality of invoices may be recorded on one blockchain, the last block before the event block for which the invoice is issued is not recorded on the blockchain is not necessarily the current invoice, possibly other invoices. For example, the block chain has recorded 6 blocks, which are respectively:

1) Issuance of invoice 1;

2) Issuance of invoice 2;

3) Invoice 1 billing:

4) Issuance of invoice 3;

5) Reimbursement of invoice 1;

6) Invoice 2.

The current invoice is invoice 3. When invoice 3 is invoiced, a block, namely a block of the invoicing event of invoice 3, needs to be added on the block chain to be used as a 7 th block, and the last block before the 7 th block is not recorded on the block chain is a 6 th block which is related to invoice 2. Just because the last block before the event block for issuing the invoice is not recorded on the unmanaged block chain, is not related to the current invoice, in one embodiment, the digest value (or the digest value of the block body) of the last block is recorded together with the digest value of the block body of the current block (or the digest value of the current block) as at least a part of the block header of the current block, so that each block on the block chain contains the information of the last block in the block chain, and the information itself is also recorded by the next block on the block chain, and a close evidence relationship is formed between the blocks, therefore, the blocks recorded by the block chain are difficult to be tampered, and the safety of storing and verifying the invoice information on the block chain is greatly improved. And according to the block body abstract value of the event block issuing the invoice, finding the event block issuing the invoice recorded on the block chain.

In step 430, when the invoice information and the invoice transfer information of the invoicing event in the found event block are respectively consistent with the invoice information and the invoice transfer information of the invoicing event in the invoice reimbursement request, a response allowing the invoice reimbursement is sent.

If the found invoice information and invoice transfer information of the invoicing event in the event block are respectively consistent with the invoice information in the invoice reimbursement request and the invoice transfer information of the invoicing event, the fact that the invoice information when invoicing is not tampered online under the condition that the employee reimburses online is shown, the printed invoice is not manually amended after the electronic invoice is printed under the condition that the invoice is reimbursed online, and otherwise, the fact that the found information in the event block is inconsistent with the information in the invoice reimbursement request is caused. If both are identical, a response is issued to the reimbursement unit terminal 101 to permit invoice reimbursement. Therefore, the invoice tampering condition is detected, and the reimbursement condition after the invoice tampering is avoided.

As shown in fig. 5, according to an embodiment of the present disclosure, after step 430, the method further includes:

step 440, receiving a reimbursement invoice transfer request, wherein the reimbursement invoice transfer request comprises invoice information and reimbursement event invoice transfer information;

and step 450, recording the invoice information and reimbursement event invoice transfer information in an event block for reimbursement of the invoice on the block chain.

The event block for reimbursing the invoice is provided with a summary value of the block main body of the event block for reimbursing the invoice, which is obtained by performing summary operation on the block main body comprising the invoice information and reimbursement event invoice transfer information.

Steps 440-450 are described in detail below.

In step 440, a reimbursement invoice transfer request is received, the reimbursement invoice transfer request including invoice information, reimbursement event invoice transfer information.

After receiving the response indicating whether the invoice is allowed to be reimbursed, the reimbursement unit terminal 101 also uplinks the invoice reimbursement event in time as shown in fig. 3B. If not, the invoice circulation subsequent link can not obtain all the information in the invoice circulation link, and when the subsequent link needs to be verified, the information is lost to cause an error conclusion. Therefore, the reimbursement unit terminal 101 needs to issue an reimbursement invoice transfer request to the blockchain gateway server 401.

In the case of online reimbursement, the reimbursement invoice transfer request is made in response to the financier selecting "YES" on the interface of FIG. 1M. In the case of online reimbursement, since the reimbursement unit is not online, it will not care about recording reimbursement events to the blockchain. It may query blockchain gateway server 401 using the method of the embodiments of the present disclosure to determine whether reimbursement is allowed, but not record reimbursement events to the blockchain, in order to verify whether invoices have been tampered with or reimbursed.

The reimbursement invoice transfer request comprises invoice information and reimbursement event invoice transfer information. As shown in fig. 1N, the invoice information is automatically generated according to information in an electronic invoice transmitted to a reimbursement unit terminal by an employee. The reimbursement event invoice transfer information in the interface includes roll-out party information, roll-in party information, roll-out party phone, etc. The forwarding party information is generated according to the information of the retriever in the invoice information, the forwarding party information is generated according to the top name of the invoice in the invoice information, and the forwarding party telephone is generated according to the telephone of the retriever in the invoice information. The chain of the invoice information and the invoice transfer information of the reimbursement event plays an important role in the verification of subsequent links (such as an auditing link, a tax payment link and a repeated reimbursement link). The uplink of the invoice information ensures that the subsequent link can verify whether the invoice related to the subsequent link is a non-tampered invoice, and the invoice transfer information has important information for verifying repeated reimbursement, which will be described in detail later.

In step 450, the invoice information and reimbursement event invoice transfer information are recorded in an event block for reimbursement of the invoice on a block chain, wherein the event block for reimbursement of the invoice has a digest value of a block body of the event block for reimbursement of the invoice obtained by performing digest operation on the block body including the invoice information and reimbursement event invoice transfer information.

As shown in fig. 6, in one embodiment, step 450 may comprise:

step 4501, performing summary operation on the block main body including the invoice information and reimbursement event invoice transfer information to generate a summary value of the block main body of the event block reimbursement the invoice;

step 4502, taking the summary value of the block body of the event block reimbursing the invoice together with the summary value of the last block before the event block on the block chain where the reimbursement of the invoice is not recorded as at least a part of the block header of the event block reimbursing the invoice;

step 4503, using the invoice information, reimbursement event invoice transfer information as at least a part of the block body of the event block reimbursement the invoice;

step 4504, concatenate the block header and the block body as the event block for reimbursing the invoice to be recorded in the block chain.

These steps are described in detail below.

The digest operation in step 4501 may be a hash algorithm or the like. The method can be the same operation as the abstract operation of the invoice information and the invoice transfer information of the invoicing event in the invoicing link. In one embodiment, the same abstract algorithm may also be set for different abstract algorithms for different invoices, and in the links of issuing, invoicing, reimbursement and the like of the same invoice. The blockchain gateway server 401 may maintain a table of invoice id to summary algorithm correspondences. When the summarization operation is required in 4501, the corresponding relationship table is searched according to the invoice identifier (invoice code + invoice number) in the invoice information, so as to obtain a summarization algorithm, and summarization operation is performed. The method has the advantages that different abstract algorithms are aimed at different invoices, so that abstract values are difficult to crack, and the safety of block record information is further improved.

In step 4502, similar to the above-mentioned case of event block record of invoicing, the summary value of the block body of the event block reimbursing the invoice is recorded in the block header of the event block reimbursing the invoice together with the summary value of the last block before the event block reimbursing the invoice is not recorded in the block chain, and the significance is that each block in the block chain contains information of the previous block in the block chain, the block information of the block itself is also recorded by the next block in the block chain, and a close evidence printing relationship is formed between the blocks, so that the block recorded in the block chain is difficult to be tampered, and the safety of storage and verification of the invoice information on the block chain is greatly improved.

The block header records a timestamp, a check code, and the like, in addition to the digest value of the block body of the event block for reimbursing the invoice and the digest value of the last block before the event block for reimbursing the invoice which is not recorded in the block chain. The time stamp records the time when the block was generated, and is automatically recorded in the time stamp field of the block header when the block was generated. The check code is a bit generated by using a parity check algorithm on bits including other parts of the block header (except for the check code bits) and bits of the block body, and the bits are used for checking whether the block is changed, if the block is changed, the bits of the other parts (except for the check code bits) and the bits of the block body are operated by using the parity check algorithm, and the result is different from the check code. In this way, the block is further protected against tampering.

The formation of the block body and the block header in

steps

4503 and 4504 is similar to the above-mentioned case of event block record of invoicing, and thus is not described in detail.

The above embodiments merely avoid the situation of virtual invoice reimbursement, and in a further embodiment, can also avoid invoice reimbursement. When the blockchain gateway server 401 judges whether invoice reimbursement is allowed, the method not only judges whether invoice information and invoice transfer information of invoicing events in the found event blocks are respectively consistent with invoice information in the invoice reimbursement request and invoice transfer information of invoicing events, but also judges whether information of an invoice affiliation party registered at present is consistent with actual reimburser information.

In this embodiment, the invoice reimbursement request may also contain reimburser information. Thus, there may be an extra box (not shown) filling in "reimburser information" on the interfaces of FIGS. 1I and 2C. The financial staff of the reimbursement organization needs to fill in the box of "reimburser information" with the information of the staff actually requesting reimbursement. Thus, the invoice reimbursement request sent to the blockchain gateway server 401 contains reimburser information.

Thus, as shown in FIG. 7, step 430 may include:

4301, inquiring the information of the attribution party of the invoice when the invoice information and the invoice transfer information of the invoicing event in the found event block are respectively consistent with the invoice information in the invoice reimbursement request and the invoice transfer information of the invoicing event;

step 4302, when the inquired information of the home party is consistent with the reimburser information, sending a response allowing reimbursement of the invoice.

There are many implementations of querying the invoice owner information in step 4301.

In one embodiment, querying the attribution information of the invoice can be realized by querying the invoice turning-in party information of the latest block in the event blocks of the invoice recorded in the block chain. As described above, in the processes of issuing, invoicing, reimbursement, and the like of invoices, it is required to link events, and in the process of linking, not only the invoice information but also the invoice transfer information are linked. The invoice information contains an invoice identifier. As described above, the invoice transfer information may include invoice forwarder information, and the like. Those blocks of the invoice information on the entire blockchain that have the invoice identifier in the invoice reimbursement request are all event blocks of the invoice that are currently recorded on the blockchain. And finding the event block with the latest recording time from the event blocks, wherein the invoice transfer-in party information in the invoice transfer information is the attribution party information of the current invoice.

Thus, as in fig. 8, in this embodiment, step 4301 comprises:

step 43011, determining an event block with the latest recording time in the event blocks with the invoice identifier in the invoice reimbursement request on the block chain;

step 43012, transferring the invoice in the determined event block to party information as the attribution party information of the invoice.

The embodiment searches the information of the attribution party of the invoice by using the information of the transfer party of the invoice of the latest block in the event blocks of the invoice recorded in the block chain, realizes the determination of the information of the attribution party without additional off-chain recording, and is favorable for optimizing the resource utilization efficiency.

In addition, in other embodiments, the search of the invoice attribution information can also be realized by using a mode of recording the invoice attribution outside the block chain.

In one embodiment, the invoice attribution table outside the chain may be used for recording. In the invoice attribution table, the invoice identification of each invoice is recorded corresponding to attribution party information. This requires that the invoice attribution table be updated as well as the invoice issuance, invoicing, reimbursement events are linked. At this time, when the current invoice attribution party needs to be searched, since the invoice attribution table already records the updated invoice attribution party corresponding to each invoice identification, the attribution party information corresponding to one invoice identification can be directly read from the invoice attribution table.

In this embodiment, after step 440, the method further comprises: and replacing attribution party information in an invoice attribution table corresponding to the invoice identifier, which is set outside the blockchain, with the invoice transfer-in party information in the reimbursement event invoice transfer information.

When the invoice reimbursement event occurs, the invoice transfer-in party information in the invoice transfer information of the reimbursement event represents the party to which the invoice is transferred newly, namely the terminal of the reimbursement unit, so that the information of the home party corresponding to the corresponding invoice identifier in the invoice home table is replaced by the information of the transfer-in party, and the purpose of updating the information of the home party can be achieved.

Accordingly, the querying the attribution information of the invoice comprises: and inquiring the invoice attribution table according to the invoice identification to obtain the attribution party information. Thus, if the employee reimburses the same invoice repeatedly, if the reimbursement of the previous invoice is performed on line, the transfer of the invoice ownership is completed, or otherwise, the attribution party information in the invoice attribution table corresponding to the invoice identifier in the previous reimbursement is changed into a reimbursement unit instead of the employee, and in the reimbursement, the reimburser is still the employee, so that the reimburser is inconsistent with the invoice attribution party, and the reimbursement is not performed. In this way, duplicate reimbursements are avoided in the case where the previous reimbursement was made online. As for the case where the previous reimbursement is the line reimbursement, how to avoid the reimbursement is described later.

The above describes how to update the invoice attribution table while chaining events in the invoice reimbursement process. In the links of invoice issuing and invoicing, the invoice attribution table is also required to be updated at the same time of event chaining.

The process of updating the invoice attribute table while chaining link events for an invoice is shown in figure 9. Prior to step 410, the method includes:

step 404, receiving an invoice issuing request, wherein the invoice issuing request comprises an identifier of an event block issuing the invoice, invoice information and issue event invoice transfer information, which are recorded on a block chain;

step 405, according to the identifier of the event block issuing the invoice, searching the event block issuing the invoice recorded on the block chain;

step 406, when the found invoice information and the issue event invoice transfer information in the event block are respectively consistent with the invoice information in the invoice issuing request and the issue event invoice transfer information, sending a response allowing invoicing;

step 407, receiving an invoicing transfer request, wherein the invoicing transfer request comprises invoice information and invoicing event invoice transfer information, and the invoicing event invoice transfer information comprises invoice transfer-in party information;

step 408, recording the invoice information and invoice transfer information of the invoicing event on a block chain as at least one part of a block main body of an event block for issuing the invoice, wherein the event block for issuing the invoice has a block main body abstract value of the event block for issuing the invoice as an identifier of the event block for issuing the invoice, and the block main body abstract value of the event block for issuing the invoice is obtained by performing abstract operation on the block main body comprising the invoice information and invoice transfer information of the invoicing event;

and 409, replacing attribution party information in an invoice attribution table corresponding to the invoice identifier with invoice transfer party information in the invoice transfer information of the invoicing event.

These steps are described in detail below.

Receipt of the invoicing request in step 404 is effected in response to the invoicing unit's employee selecting a "confirm" button on the interface of the invoicing terminal 201 as shown in figure 1B. When issuing the invoice, the industrial and commercial department issues a plurality of invoices with continuous invoice numbers to the invoicing unit at one time. The invoicing terminals 201 typically issue the invoices in sequence from small to large according to the sequence of the multiple invoices, that is, the invoice number of one invoice with the smallest invoice number, which is not issued yet currently, of the multiple continuous invoices is displayed on the interface of fig. 1B. The left side of fig. 1B is automatically generated by the invoicing system according to the information inherent in the invoicing system, and the right side is filled in by the invoicing staff according to actual needs during invoicing. When the "ok" button is selected, the contents of fig. 1B are sent as invoice information to blockchain gateway server 401.

In one embodiment, the identification of the event block issuing the invoice is a digest value obtained by performing a digest operation on a block body of the event block issuing the invoice.

In another embodiment, the identification of the event block issuing the invoice is a summary value obtained by performing a summary operation on the event block (including a block body and a block header) issuing the invoice.

In another embodiment, the identification of the event block issuing the invoice is the height of the event block issuing the invoice on the blockchain.

The invoice transfer information of the issued event comprises invoice transfer party information, invoice transfer party information and the like, wherein the invoice transfer party information is generated according to the name of the industrial and commercial institution and is consistent with the name of the industrial and commercial institution; the invoice transfer-in party information is generated according to a retriever (drawer) and is consistent with the retriever (drawer). As described above, the block body digest value of the event block to issue the invoice is generated by performing a digest operation on the block body including the invoice information and the issue event invoice slip transition information.

In step 405, since the block body summary value can uniquely identify the event block from which the invoice is issued, the event block recorded on the block chain from which the invoice is issued can be found according to the block body summary value.

In step 406, when the invoice information and the issue event invoice transfer information in the found event block are respectively consistent with the invoice information and the issue event invoice transfer information in the invoice issuing request, a response allowing invoicing is sent.

If the found invoice information and the issue event invoice transfer information in the event block are respectively consistent with the invoice information and the issue event invoice transfer information in the invoice issuing request, the fact that the invoice unit does not forge the altered invoice is shown, and the invoice is legal and is allowed to be issued.

In step 407, an invoicing transfer request is received, where the invoicing transfer request includes invoice information and invoicing event invoice transfer information, and the invoicing event invoice transfer information includes invoice transfer-to-party information.

The invoice transfer request is a request to chain record the invoiced event. The invoice request issued in step 404 is simply a request to verify if there is a problem with the invoice, and if there is no problem then the invoice is allowed to be issued. But it does not record this invoice transfer process on the blockchain. If the process is not recorded, the subsequent links such as reimbursement, audit and the like lack the basis of comparison and check, and are not beneficial to the subsequent links. Therefore, the billing terminal 201 sends an invoice transfer request to the blockchain gateway server 401, and records the invoice information and the invoice transfer information of the billing event on one block of the blockchain. Invoice information may be generated according to the information on the interface shown in fig. 1B. The invoice transfer information of the invoicing event comprises invoice transfer party information, transfer party telephone and the like. The invoice roll-out information is automatically generated by the invoicing system of the invoicing terminal 201 according to the invoicer shown in fig. 1B. The invoice transfer-in party information is automatically generated by the invoice issuing system of the invoicing terminal 201 according to the retriever shown in fig. 1B. The transfer party phone is automatically generated by the invoicing system of the invoicing terminal 201 from the taker phone as shown in fig. 1B.

In step 408, the invoice information and the invoice transfer information of the invoicing event are recorded on a block chain as at least a part of a block main body of an event block issuing the invoice, the event block issuing the invoice has a summary value of the block main body of the event block issuing the invoice as an identifier of the event block issuing the invoice, and the block main body summary value of the event block issuing the invoice is obtained by performing summary operation on the block main body including the invoice information and the invoice transfer information of the invoicing event.

In one embodiment, the block body including the invoice information and the invoice transfer information of the invoicing event can be subjected to a summarization operation to obtain a block body summary value. Then, a block is newly generated on the block chain. And taking the obtained block main body abstract value and the abstract value of the previous block on the block chain as at least one part of the block head of the new block. And taking the invoice information and the invoice transfer information of the invoicing event as at least one part of the block main body of the new block.

In step 409, the invoice transfer-in party information in the invoice transfer information of the invoicing event is used for replacing the attribution party information in the invoice attribution table corresponding to the invoice identification.

The invoice attribution table records the invoice placing identification and the latest attribution party information of the invoice. Before invoicing, the attribution party information of the corresponding invoice identifier recorded in the invoice attribution table is an invoicing unit, but after invoicing, the attribution party of the invoice is changed to become an invoice retriever, namely invoice transfer-in party information in the invoice transfer information of the invoicing event. Therefore, after invoicing, besides the invoicing event needing to be linked, the invoice transfer party information in the invoicing event invoice transfer information needs to be used for replacing the attribution party information in the invoice attribution table corresponding to the invoice identifier, and updating of the invoice attribution party is completed. Therefore, convenience is provided for checking the attribution party of the invoice in the subsequent verification link.

The process of updating the invoice attribution table while chaining the link events of issuing the invoice is shown in figure 9.

Prior to step 404, the method includes:

step 401, receiving an invoice issuing request, wherein the invoice issuing request comprises invoice information and issue event invoice transfer information;

step 402, recording the invoice information and the issue event invoice transfer information in a block chain as at least a part of a block main body of an event block issuing the invoice, wherein the event block issuing the invoice has a summary value of the block main body of the event block issuing the invoice as an identifier of the event block issuing the invoice, and the block main body summary value of the event block issuing the invoice is obtained by performing summary operation on the block main body including the invoice information and the issue event invoice transfer information;

and 403, writing the invoice transfer party information in the issue event invoice transfer information into an invoice attribution table corresponding to the invoice identifier as attribution party information.

Steps 401-403 are described in detail below.

Receipt of the invoice issuance request in step 401 is in response to a worker at the business institution selecting the "ok" button on the interface of the invoice issuance system shown in fig. 1A. The invoice information contained in the request for issuance of an invoice is the information shown in the interface of fig. 1A. The issue event invoice transfer information includes invoice roll-out party information, invoice roll-in party information, and the like. The invoice forwarder information is automatically generated by the invoice issuing system of the invoice issuing terminal 301 from the issuing authority information in fig. 1A. The invoice transfer destination information is generated automatically by the invoice issuing system of the invoice issuing terminal 301 from the claim invoice entity information in fig. 1A.

In step 402, in one embodiment, a block body including the invoice information and the issue event invoice transfer information may be subjected to a digest operation to obtain a block body digest value. Then, a block is generated on the blockchain, and the block is the first block recorded on the blockchain by the invoice. In one embodiment, the obtained block body digest value is placed in the block header of the block together with the digest value of the block body of the previous block on the block chain. In another embodiment, the obtained block body digest value may also be placed in the block header of the block together with the digest value of the previous block (including the block body and the block header) in the block chain. And placing the invoice information and the issue event invoice transfer information in the block main body of the block.

The invoice attribution table records the invoice issuing identification and latest attribution party information of the invoice. Before the invoice is issued, the invoice attribution table does not record any corresponding relation record of the invoice identification corresponding to the invoice identification and attribution party information. The invoice issuance event block recorded at the time of invoice issuance is the first record in the invoice attribution table for that invoice identification. The invoice owner is the industry and commerce department before the invoice is issued. After the invoice is issued, it becomes a claimed invoice unit, i.e., a billing unit. Therefore, after the invoice is issued, besides the invoice issue event needs to be linked conveniently to check the authenticity of the invoice, the invoice transfer party information in the invoice transfer information of the invoice issue event needs to be written into the invoice attribution table as the attribution party information corresponding to the invoice identifier. Therefore, convenience is provided for checking the attribution party of the invoice in the subsequent verification link.

In one embodiment, in addition to employing invoice attribution tables outside the chain, an invoice transfer registry outside the chain may also be employed. In the invoice transfer registration table, the information of the current invoice attribution party can be obtained as well.

In this embodiment, after step 440, the method further comprises: and recording the reimbursement event invoice transfer information in an invoice transfer registration table which is arranged outside the blockchain and corresponds to the invoice identifier. The invoice transfer registry records invoice transfer information for each event that occurs corresponding to an invoice identification. Each invoice id corresponds to an invoice transfer registry. For example, the issue, invoice, reimbursement event invoice transfer information corresponding to one invoice identifier is recorded in the invoice transfer registry corresponding to this invoice identifier. The invoice transfer information includes invoice transferor information, and the like. When the invoice is issued, the invoice transfer registration table records the invoice transfer information of the issue event corresponding to the invoice identification. After invoicing, the invoice transfer registration form not only records the issue event invoice transfer information corresponding to the invoice identification, but also records the invoice transfer information of the invoicing event corresponding to the invoice identification. After reimbursement, the invoice transfer registration form records not only the issue event invoice transfer information and the invoicing event invoice transfer information corresponding to the invoice identification, but also the reimbursement event invoice transfer information corresponding to the invoice identification. The method has the advantages that not only is static information of a current time point recorded, but also the history of the whole transfer process of the invoice is recorded.

In this embodiment, after step 440, the method further comprises: and recording the reimbursement event invoice transfer information in an invoice transfer registration table which is arranged outside the blockchain and corresponds to the invoice identifier. When recording, the reimbursement event invoice transfer information and the invoice identification can be recorded correspondingly.

Accordingly, the querying the attribution information of the invoice comprises: and inquiring the invoice transfer registration table according to the invoice identifier, wherein each invoice transfer information in the invoice transfer registration table has invoice transfer-in party information, and the invoice transfer-in party information in the last invoice transfer information in the invoice transfer registration table is used as the attribution party information. The last invoice transfer information of the invoice transfer registry represents the last event that occurs currently on the invoice, and the invoice transfer party information in the event is ownership owner information of the current invoice.

The above describes how to update the invoice transfer registry at the same time as the chain of events in the invoice reimbursement process. In the links of invoice issuing and invoicing, the invoice transfer register table is also required to be updated at the same time of event chaining.

The process of updating the invoice transfer registry at the same time as chaining the billing link events is shown in figure 10. Prior to step 410, the method includes:

step 404', receiving an invoice issuing request, wherein the invoice issuing request comprises an identifier of an event block issuing the invoice, invoice information and issue event invoice transfer information, which are recorded on a block chain;

step 405', according to the identifier of the event block issuing the invoice, searching the event block issuing the invoice recorded on the block chain;

step 406', when the invoice information and the issue event invoice transfer information in the found event block are respectively consistent with the invoice information in the invoice reimbursement request and the issue event invoice transfer information, sending a response allowing invoicing;

step 407', receiving an invoicing transfer request, wherein the invoicing transfer request comprises invoice information and invoicing event invoice transfer information, and the invoicing event invoice transfer information comprises invoice transfer-in party information;

step 408', recording the invoice information and invoice transfer information of the invoicing event on a block chain as at least one part of a block main body of an event block for issuing the invoice, wherein the event block for issuing the invoice has a block main body abstract value of the event block for issuing the invoice as an identifier of the event block for issuing the invoice, and the block main body abstract value of the event block for issuing the invoice is obtained by performing abstract operation on the block main body comprising the invoice information and invoice transfer information of the invoicing event;

and 409', recording the invoice transfer information of the invoicing event in an invoice transfer registration table corresponding to the invoice identifier.

Steps 404'-408' are substantially identical to steps 404-408, respectively, and therefore are not repeated. In step 409', the invoice transfer information of the invoicing event is recorded in an invoice transfer registry corresponding to the invoice identification. Before the occurrence of the billing event, the invoice transfer register table records the invoice information of the issue event corresponding to the invoice identifier and the issue event invoice transfer information. And after the invoicing event occurs, adding and recording invoice information of the invoicing event corresponding to the invoice identification and invoice transfer information of the invoicing event in the invoice transfer registration table. Therefore, convenience is provided for checking the affiliation party of the invoice and even checking the information in the whole invoice transfer process in the subsequent verification link.

The process of updating the invoice transfer registry at the same time as the link event link for issuing the invoice is shown in figure 10. Prior to step 404', the method includes:

step 401', receiving an invoice issuing request, wherein the invoice issuing request comprises invoice information and invoice transfer information of an invoicing event;

step 402', recording the invoice information and invoice transfer information of the invoicing event on a block chain as at least one part of a block main body of an event block issuing the invoice, wherein the event block issuing the invoice has a block main body abstract value of the event block issuing the invoice as an identifier of the event block issuing the invoice, and the block main body abstract value of the event block issuing the invoice is obtained by performing abstract operation on the block main body comprising the invoice information and transfer information of the issued event invoice;

step 403', recording the issue event invoice transfer information in an invoice transfer registry corresponding to the invoice identifier.

Steps 401'-403' are described in detail below.

Steps 401'-402' are similar to steps 401-402, and thus are not repeated. In step 403', the issue event invoice transfer information is recorded in an invoice transfer registry corresponding to the invoice identification. Before the invoice is issued, the invoice does not exist, and the corresponding invoice identifier also exists, so that the invoice transfer registration table corresponding to the invoice identifier is not created. After the invoice is issued, an invoice transfer registration table corresponding to each issued invoice identifier is created, and the issue event invoice transfer information is recorded in the invoice transfer registration table corresponding to the invoice identifier. As shown in fig. 1A, 100 invoices with an invoice code of 2873ERST2 and an invoice number of 100001-100100 may be issued together, corresponding invoice transfer registers are established for the 100 invoices respectively, and issue event invoice transfer information including an invoice forwarder and a forwarder is written into the invoice transfer registers.

In one embodiment, the reimbursement event invoice transfer information has invoice exporter information and invoice importer information. As in fig. 11, after step 450, the method further comprises:

step 460, receiving a reimbursement and payment request, wherein the payment request comprises information of a requester;

step 470, if the event block with the latest recording time of the invoice identifier in the block chain contains reimbursement event invoice transfer information, invoice transfer-out party information in the reimbursement event invoice transfer information is consistent with information of the applicant, and invoice transfer-in party information in the reimbursement event invoice transfer information is consistent with information of the sender of the reimbursement and reimbursement request, sending a response of allowing reimbursement.

In this embodiment, the process of reimbursement and payment occurs after the chain of reimbursement events and the registered ownership of the invoice is transferred, which is beneficial to ensuring that the invoice is used as an asset when the payment is made, and the ownership of the invoice is already transferred, that is, the transfer of money is performed only after the asset is transferred, so that the security of payment is improved.

After the chain of the reimbursement event and the transfer of the registered invoice ownership occur, the employee may operate the loan request on the employee terminal 102, for example, may perform some operation on the display interface of the electronic invoice in the card package (for example, touching a "loan request" button on the interface) to request the loan from the reimbursement entity terminal 101. After receiving the request of the employee, the reimbursement unit terminal 101 sends a reimbursement and payment request to the blockchain gateway server 401, and a payee information is automatically added to the request according to the employee (owner of the employee terminal) who requests payment. When the blockchain gateway server 401 receives the reimbursement and payment request, it first checks whether the last block with the invoice id recorded on the blockchain is a reimbursement event block (this can be determined from whether the reimbursement event invoice transfer information is included). If the invoice is not the reimbursement event block, the transfer of the invoice ownership in reimbursement is not completed, and the payment cannot be made. If the block is the reimbursement event block, whether the invoice transfer-out side information in the reimbursement event invoice transfer information is consistent with the information (staff) of the applicant or not and whether the invoice transfer-in side information in the reimbursement event invoice transfer information is consistent with the sender (reimbursement unit) of the reimbursement and payment request or not are also checked. If the two are consistent, the money can be placed. If not, refusing to deposit.

The above process is more apparent in the interaction flow diagram of fig. 13A. When the staff needs to report the reimbursement online, the electronic invoice is transmitted to the reimbursement unit terminal 101 through the electronic invoice system. The reimbursement unit terminal 101 sends an invoice reimbursement request to the blockchain gateway server 401, so that the blockchain gateway server 401 checks authenticity of the invoice and determines whether the invoice belongs to repeated reimbursement. If the invoice is true and does not belong to duplicate reimbursements, the blockchain gateway server 401 sends an acknowledgement to the reimbursement unit terminal 101 that allows reimbursement. The reimbursement unit terminal 101 transmits a response of completion of reimbursement to the employee terminal 102. The reimbursement unit terminal 101 also sends an reimbursement invoice transfer request to the blockchain gateway server 401. After receiving the request, the blockchain gateway server 401 links the invoice reimbursement event and updates relevant invoice attribution information (e.g., invoice attribution table, invoice transfer registry, etc. outside the chain). When the employee terminal 102 requests the deposit, the reimbursement unit terminal 101 queries the blockchain gateway server 401 whether the invoice has been subjected to ownership transfer, that is, uplinked and the attribution information is updated. If so, the blockchain gateway server 401 sends a response that the transfer has been completed to the reimbursement unit terminal 101. Then, the reimbursement unit terminal 101 deposits money to the employee terminal 102, for example, by WeChat transfer or the like.

As described above, if the employee reimburses the same invoice, if the reimbursement is performed on-line, the reimbursement must be performed during the on-line reimbursement, and the ownership of the invoice is transferred to the reimbursement unit, so that the reimburser at this time is inconsistent with the owner of the invoice. In this way, duplicate reimbursements are avoided in the case where the previous reimbursement was made online. However, if the previous reimbursement is an offline reimbursement, the offline reimbursement will not proceed with the uplink reimbursement event and the invoice ownership registration will be transferred to the reimbursement entity, and it will not be possible to detect if reimbursement has occurred. In order to detect the duplicate reimbursement even in the case where the previous reimbursement was a line reimbursement (a reimbursement in some units without an on-line condition after printing the electronic invoice), in one embodiment, the duplicate reimbursement in the case where the previous reimbursement was a line reimbursement is prevented by: once the electronic invoice is printed, the electronic invoice is recorded as a locking state, and once the invoice is recorded as the locking state, reimbursement is allowed only once, namely, a response for allowing reimbursement of the invoice is sent to a receiving invoice reimbursement request with the invoice identification received for the first time after locking. In this way, if the invoice reimbursement request is received for the second time after the electronic invoice is printed, reimbursement is not allowed, thereby preventing reimbursement in the case where the previous reimbursement was a line reimbursement.

As shown in fig. 12, in one embodiment, prior to step 410, the method further comprises:

step 4001, receiving an invoice offline printing request, wherein the invoice offline printing request has an invoice identifier;

step 4002, recording the invoice corresponding to the invoice identifier as a locked state, where the locked state only allows sending a response allowing reimbursement of the invoice to a received invoice reimbursement request having the invoice identifier received for the first time after recording the invoice corresponding to the invoice identifier as the locked state;

step 4003, printing the invoice, wherein the invoice is printed with a graphic code which is recorded on a block chain and corresponds to the identifier of the event block which issues the invoice and has the identifier of the invoice.

In step 4001, after the employee terminal 102 selects "connected and print started" as shown in fig. 2A, the employee sends an invoice offline print request to the blockchain gateway server 401. Since the wechat card package of fig. 1H stores invoice information including an invoice identifier therein, the wechat card package can automatically add the invoice identifier to the invoice offline printing request. After receiving the offline printing request of the invoice, the blockchain gateway server 401 records the corresponding invoice as a locked state according to the invoice identifier therein. The method of recording the lock status is described below. Then, printing the invoice is started, and the printed invoice is printed with a graphic code such as a two-dimensional code, wherein the graphic code corresponds to the identifier of the event block which is recorded on the block chain, has the invoice identifier and issues the invoice, and the identifier uniquely identifies the event block issuing the invoice.

Therefore, when the employee takes the printed invoice to a financial staff of a reimbursement unit for reimbursement, the financial staff scans the graphic code by using a scanner and obtains the identification of the event block issuing the invoice. In this case, step 4302 includes: and when the inquired information of the attribution party is consistent with the reimburser information, if the invoice corresponding to the invoice identifier is determined not to be in a locked state or the invoice reimbursement request received although the invoice corresponding to the invoice identifier is in the locked state is the invoice reimbursement request received for the first time after the invoice corresponding to the invoice identifier is recorded in the locked state and provided with the invoice identifier, sending a response for allowing the invoice reimbursement.

That is, the inquired information of the attribution party is consistent with the reimburser information, and only the repeated reimbursement when the previous reimbursement was an online reimbursement can be prevented. If the last reimbursement is an offline reimbursement, the invoice identifier may be prevented from being received for the first time after the invoice corresponding to the invoice identifier is recorded as a locked state by determining whether the invoice corresponding to the invoice identifier is not in a locked state or whether the invoice reimbursement request received although the invoice identifier is in a locked state is a received invoice reimbursement request with the invoice identifier received for the first time after the invoice corresponding to the invoice identifier is recorded as a locked state. If the invoice corresponding to the invoice identification is not in a locked state, the invoice does not print the invoice line for reimbursement, and therefore the invoice identification is safe. If in the locked state, it is determined that the receipt of the invoice reimbursement request with the invoice identification is received a few times. If it is the first time, it is still safe. If the number of times is later, the reimbursement is repeated. In this way, duplicate reimbursements where the previous reimbursement was a line reimbursement are prevented.

In one embodiment, determining that the invoice corresponding to the invoice identifier is not in a locked state is performed by:

setting a locking information table corresponding to an invoice identifier, wherein when the invoice corresponding to the invoice identifier is recorded as a locking state, the locking state is recorded in the locking information table corresponding to the invoice identifier;

searching a locking information table corresponding to the invoice identification according to the invoice identification in the received invoice reimbursement request;

and if the locking state is not recorded in the locking information table, determining that the invoice corresponding to the invoice identifier is not in the locking state.

In one embodiment, a corresponding locking information table is provided for each invoice identification. If the invoice is not recorded as a lockout condition, the lockout information table does not store any information. Alternatively, the lock information table may be generated only after the lock status is recorded for the invoice. And when the locking state is recorded for the invoice, recording the locking state in a locking information table corresponding to the invoice identifier. For example, a specific field of the lock information table is set to 1. At this time, when it is required to determine whether the invoice corresponding to the invoice identifier is in a locked state, it is only required to search the locked information table corresponding to the invoice identifier according to the invoice identifier in the received invoice reimbursement request, and determine whether a corresponding field in the locked information table is set to 1. If set 1 indicates locked, if not set 1 indicates unlocked.

In addition, in this embodiment, the invoice reimbursement request received after determining that the invoice corresponding to the invoice identifier is in the locked state is the invoice reimbursement request having the invoice identifier received for the first time after recording the invoice corresponding to the invoice identifier in the locked state may be performed in the following manner:

setting a locking information table corresponding to an invoice identifier, wherein when the invoice corresponding to the invoice identifier is recorded as a locking state, the locking state is recorded in the locking information table corresponding to the invoice identifier, and in response to receiving an invoice reimbursement request with the invoice identifier, the invoice reimbursement request is recorded in the locking information table;

if the locking state is recorded in the locking information table and the invoice reimbursement request is not recorded in the locking information table, the invoice corresponding to the invoice identifier is determined to be in the locking state, but the received invoice reimbursement request is the first received invoice reimbursement request with the invoice identifier after the invoice corresponding to the invoice identifier is recorded in the locking state.

That is, the lock information table records not only whether the invoice is in a locked state but also an invoice reimbursement request received after being in the locked state. Thus, if the locking state is recorded in the locking information table, but no invoice reimbursement request is recorded in the locking information table, it indicates that the invoice marked by the invoice is reimbursed after locking. If the invoice has been reimbursed, there will be an invoice reimbursement request in the locking information table. Thus, it is determined that the situation is not reissued, and reissue may be allowed.

The above process is more apparent in the interaction flow diagram of FIG. 13B. When the employee needs to print the electronic invoice, the employee sends an invoice offline printing request to the blockchain gateway server 401 before printing the electronic invoice. After receiving the request, blockchain gateway server 401 records the invoice as a locked state. The employee terminal 102 prints the invoice. The employee takes the printed invoice to the financial staff of the reimbursement unit for reimbursement. The reimbursement unit terminal 101 transmits an invoice reimbursement request to the blockchain gateway server 401. The blockchain gateway server 401 checks the invoice for authenticity and determines whether the invoice is a duplicate invoice (including determining whether the invoice currently belongs to the employee, determining whether the invoice is in a locked state, or requesting reimbursement for the first time although the invoice is in a locked state). If the invoice is true and does not belong to duplicate reimbursements, a response is sent to the reimbursement unit terminal 101 allowing reimbursement. The reimbursement unit terminal 101 transmits a response of completion of reimbursement to the employee terminal 102. Because of the offline reimbursement, the reimbursement unit terminal 101 does not need to, and generally does not, send a reimbursement invoice transfer request to the blockchain gateway server 401.

The invoice issuing terminal 301, the invoicing terminal 201 and the invoice reimbursement terminal 101 uplink invoice information and invoice transfer information in the invoice issuing event, the invoice issuing event and the invoice reimbursement event. However, in some cases, due to lack of records at the invoice issuing terminal 301, the billing terminal 201, and the invoice reimbursement terminal 101, the terminals may call into question data recorded in the block chain at that time and then linked up the block chain, and the data may be considered inconsistent with the data linked up the block chain. In order to increase their reliability on the authenticity of the uplink data, in one embodiment, a method of simultaneously transmitting signatures during uplink is employed.

In one embodiment, at the time of registration of each terminal, a unique signature algorithm is allocated to each terminal (including the invoice issuing terminal 301, the invoicing terminal 201, the invoice reimbursement terminal 101 and the employee terminal 102) and is stored in the respective terminal. The signature algorithms of each terminal may be different from each other. In this embodiment, the reimbursement invoice transfer request includes reimbursement terminal signature information for the invoice information and reimbursement event invoice transfer information in addition to the invoice information and reimbursement event invoice transfer information. The reimbursement terminal signature information is obtained by the invoice reimbursement terminal 101 electronically signing the invoice information and reimbursement event invoice transfer information by a signature algorithm assigned by itself.

In this embodiment, step 450 includes: and recording the invoice information, reimbursement event invoice transfer information and the reimbursement terminal signature information on a block chain as at least one part of a block main body of an event block reimbursing the invoice, wherein the event block reimbursement of the invoice has a block main body abstract value of the event block reimbursement of the invoice obtained by carrying out abstract operation on the block main body comprising the invoice information, the reimbursement event invoice transfer information and the reimbursement terminal signature information and is used as an identifier of the event block reimbursement of the invoice. That is, in this case, the tile body of the reimbursement event tile recorded on the tile chain includes the invoice information, reimbursement event invoice transfer information, the reimbursement terminal signature information, instead of only including the former two. The block body abstract value of the current block body included in the block header of the event block is obtained by performing abstract operation on the whole block body including the invoice information, reimbursement event invoice transfer information and reimbursement terminal signature information instead of only performing abstract operation on the invoice information and reimbursement event invoice transfer information.

Also, in the invoicing phase of this embodiment, the upper chain invoicer signature information is required. In this embodiment, the block body digest value of the event block issuing the invoice is generated by performing a digest operation on the entire block body including the invoice information, the invoicing event invoice transfer information, and the invoicing party signature information of the invoicing terminal on the invoice information and the invoicing event invoice transfer information. The event block of invoicing comprises:

a block body digest value of the invoiced event block, which is at least a part of a block header of the invoiced event block, and a digest value of a last block before the invoiced event block is not recorded on the block chain, the block body digest value of the invoiced event block being obtained by performing a digest operation on a block body including the invoice information, invoiced event invoice transfer information, and the invoicer signature information;

the invoice information, invoicing event invoice transfer information, the invoicing party signature information being at least a portion of a tile body of the invoiced event tile.

That is to say, the block body of the billing event block of the embodiment includes not only the invoice information and the billing event invoice transfer information, but also the billing party signature information, and the block header includes a block body digest value obtained by performing digest operation on not only the invoice information and the billing event invoice transfer information, but also the billing party signature information. The signature information of the invoicing party is obtained by the invoicing terminal by signing the invoice information and the invoice transfer information of the invoicing event by using a signature algorithm specific to the invoicing terminal.

Also, in the invoice issuing link of this embodiment, the ul issuer signature information is also required. In this embodiment, the block body digest value of the event block to which the invoice is issued is generated by performing a digest operation on the block body including the invoice information, the invoice issue event invoice transfer information, and issuer signature information of the issue terminal on the invoice information and the invoice issue event invoice transfer information. The event block issuing the invoice comprises:

a block body digest value of an event block issuing the invoice, which is at least a part of a block header of the event block issuing the invoice, and a digest value of a last block before the event block issuing the invoice is not recorded on the block chain, the block body digest value of the event block issuing the invoice being obtained by performing a digest operation on a block body including the invoice information, invoice issuance event invoice transfer information, and issuance terminal signature information obtained by an issuance terminal electronically signing the issuance information and invoice issuance event invoice transfer information using a signature algorithm specific to the issuance terminal;

By adding the signature information in the block main body of the block chain, the block main body abstract value in the block head is also generated according to the whole block main body comprising the invoice information, the invoice transfer information and the signature information, and the non-repudiation of the invoice related record information in the block chain is improved.

According to an embodiment of the present disclosure, as shown in fig. 14, there is also provided an information processing apparatus in invoice reimbursement, including:

a first receiving unit 510, configured to receive an invoice reimbursement request, where the invoice reimbursement request includes an identifier of an event block that issues the invoice, the identifier being recorded on a block chain, invoice information, and invoice transfer information of an invoicing event;

a first searching unit 520, configured to search, according to the identifier of the event block issuing the invoice, the event block issuing the invoice recorded on the block chain;

a first sending unit 530, configured to send a response that the invoice reimbursement is allowed when the invoice information and the invoice transfer information of the invoicing event in the found event block are consistent with the invoice information and the invoice transfer information of the invoicing event in the invoice reimbursement request, respectively.

In one embodiment, the apparatus further comprises:

a second receiving unit (not shown) for receiving a reimbursement invoice transfer request, wherein the reimbursement invoice transfer request includes invoice information and reimbursement event invoice transfer information;

a first recording unit (not shown) for recording the invoice information and reimbursement event invoice transfer information as at least a part of event blocks reimbursing the invoice on a block chain, wherein the event blocks reimbursement the invoice have a block main body summary value of the event blocks reimbursement the invoice obtained by performing summary operation on a summary main body including the invoice information and reimbursement event invoice transfer information.

In one embodiment, the first recording unit is further configured to:

performing summary operation on the block main body comprising the invoice information and reimbursement event invoice transfer information to generate a block main body summary value of an event block reimbursed for the invoice;

taking the block body summary value of the event block reimbursing the invoice together with the summary value of the last block before the event block on the block chain where the reimbursement of the invoice was not recorded as at least part of the block header of the event block reimbursing the invoice;

taking the invoice information and reimbursement event invoice transfer information as at least one part of a block main body of an event block of the reimbursement event invoice;

and connecting the block head and the block main body in series to serve as an event block for reimbursing the invoice so as to record the event block in a block chain.

In one embodiment, the block body summary value of the invoiced event block is generated by performing a summary operation on the block body including invoice information and invoiced event invoice transfer information. The event block for invoicing comprises:

a block body digest value of the invoiced event block that is at least a portion of a block header of the invoiced event block and a digest value of a last block on the block chain before the invoiced event block is not recorded;

the invoice information, invoicing event invoice transfer information being at least a portion of a tile body of the invoiced event tile.

In one embodiment, the invoice reimbursement request also contains reimburser information. The first sending unit 530 is further configured to:

inquiring the information of the attribution party of the invoice when the invoice information and the invoice transfer information of the invoicing event in the found event block are respectively consistent with the invoice information in the invoice reimbursement request and the invoice transfer information of the invoicing event;

and when the inquired information of the attribution party is consistent with the reimburser information, sending a response allowing reimbursement of the invoice.

In one embodiment, the invoice information includes an invoice identification, and the reimbursement event invoice transfer information includes invoice transfer-in party information. The inquiring of the information of the attribution party of the invoice comprises the following steps:

determining an event block with the latest recording time in the event blocks with the invoice identifications in the invoice reimbursement request on the block chain;

and transferring the invoice in the determined event block into party information to serve as attribution party information of the invoice.

In one embodiment, the invoice information includes an invoice identification, and the reimbursement event invoice transfer information includes invoice transfer-in party information. The device further comprises: a first replacing unit (not shown) for replacing the attribution party information in the invoice attribution table corresponding to the invoice identifier, which is set outside the blockchain, with the invoice transfer party information in the reimbursement event invoice transfer information. The inquiring of the information of the attribution party of the invoice comprises the following steps: and inquiring the invoice attribution table according to the invoice identification to obtain the attribution party information.

In one embodiment, the apparatus further comprises:

a third receiving unit (not shown) for receiving an invoice issuing request, where the invoice issuing request includes an identifier of an event block issuing the invoice, invoice information, and issue event invoice transfer information, which are recorded on a block chain;

a second searching unit (not shown) for searching the event block issuing the invoice recorded on the block chain according to the identifier of the event block issuing the invoice;

a second sending unit (not shown) for sending a response of allowing invoicing when the invoice information and the issue event invoice transfer information in the found event block are respectively consistent with the invoice information in the invoice reimbursement request and the issue event invoice transfer information;

a fourth receiving unit (not shown) for receiving an invoicing transfer request, wherein the invoicing transfer request includes invoice information and invoicing event invoice transfer information, and the invoicing event invoice transfer information includes invoice transfer-to-party information;

a second recording unit (not shown) configured to record the invoice information and the invoice transfer information of the invoicing event as event blocks for issuing the invoice, on a block chain, where the event blocks for issuing the invoice have block main body digest values of the event blocks for issuing the invoice, and the block main body digest values of the event blocks for issuing the invoice are obtained by performing a digest operation on block main bodies including the invoice information and the invoice transfer information of the invoicing event;

and a second replacing unit (not shown) for replacing the attribution party information in the invoice attribution table corresponding to the invoice identifier with the invoice transfer party information in the invoice transfer information of the invoicing event.

In one embodiment, the apparatus further comprises:

a fifth receiving unit (not shown) for receiving an issue invoice request, wherein the issue invoice request includes invoice information and issue event invoice transfer information;

a third recording unit (not shown) for recording the invoice information and issue event invoice transfer information on a blockchain as at least a part of a block body of an event block issuing the invoice, wherein the event block issuing the invoice has a block body digest value of the event block issuing the invoice as an identifier of the event block issuing the invoice, and the block body digest value of the event block issuing the invoice is obtained by performing a digest operation on the block body including the invoice information and issue event invoice transfer information;

and a writing unit (not shown) for writing the invoice transfer party information in the issue event invoice transfer information into an invoice attribution table as attribution party information corresponding to the invoice identifier.

In one embodiment, the reimbursement event invoice transfer information has invoice exporter information and invoice importer information. The device further comprises:

a sixth receiving unit (not shown) for receiving a reimbursement and deposit request, wherein the deposit request has information of an applicant;

and a response unit (not shown) configured to send a payment-allowed response if an event block with the latest recording time of the invoice identifier in the block chain contains reimbursement event invoice transfer information, invoice transfer-out party information in the reimbursement event invoice transfer information is consistent with applicant information, and invoice transfer-in party information in the reimbursement event invoice transfer information is consistent with sender information of the reimbursement payment request.

In one embodiment, the apparatus further comprises:

a seventh receiving unit, configured to receive an invoice offline printing request, where the invoice offline printing request has an invoice identifier;

the locking state recording unit is used for recording the invoice corresponding to the invoice identifier as a locking state, and the locking state only allows the invoice reimbursement permission response to the invoice reimbursement receiving request with the invoice identifier received for the first time after the invoice corresponding to the invoice identifier is recorded as the locking state;

and the printing unit is used for printing the invoice, and the invoice is printed with a graphic code which is recorded on a block chain and corresponds to the identifier of the event block which issues the invoice and has the identifier of the invoice.

The identification of the event block which issues the invoice in the received invoice reimbursement request is obtained by scanning the graphic code, and the invoice information in the received invoice reimbursement request comprises the invoice identification.

When the inquired information of the attribution party is consistent with the reimburser information, sending a response allowing reimbursement of the invoice, wherein the response comprises the following steps: and when the inquired attribution party information is consistent with the reimburser information, if the invoice corresponding to the invoice identifier is determined not to be in a locked state or the invoice reimbursement request received although the invoice corresponding to the invoice identifier is in the locked state is the invoice reimbursement request received for the first time after the invoice corresponding to the invoice identifier is recorded in the locked state and provided with the invoice identifier, sending a response for allowing reimbursement of the invoice.

In one embodiment, the reimbursement invoice transfer request further includes reimbursement terminal signature information for the invoice information, reimbursement event invoice transfer information.

The recording the invoice information and reimbursement event invoice transfer information as at least one part of a block main body of an event block reimbursing the invoice on a block chain includes: and recording the invoice information, reimbursement event invoice transfer information and reimbursement terminal signature information on a block chain as at least one part of an event block for reimbursing the invoice, wherein the event block for reimbursement of the invoice has a block body abstract value of the event block for reimbursement of the invoice, which is obtained by performing abstract operation on a block body comprising the invoice information, reimbursement event invoice transfer information and reimbursement terminal signature information.

The anchor label establishment method according to the embodiments of the present disclosure may be implemented by the blockchain gateway server 401 of fig. 15. A blockchain gateway server 401 according to an embodiment of the present disclosure is described below with reference to fig. 15. The blockchain gateway server 401 shown in fig. 15 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present disclosure.

As shown in fig. 15, the blockchain gateway server 401 is in the form of a general purpose computing device. The components of the blockchain gateway server 401 may include, but are not limited to: the at least one processing unit 810, the at least one memory unit 820, and a bus 830 that couples the various system components including the memory unit 820 and the processing unit 810.

Wherein the storage unit stores program code that can be executed by the processing unit 810, such that the processing unit 810 performs the steps according to various exemplary embodiments of the present invention described in the description part of the above exemplary methods of the present specification. For example, the processing unit 810 may perform the various steps as shown in fig. 4.

The memory unit 820 may include readable media in the form of volatile memory units, such as a random access memory unit (RAM) 8201 and/or a cache memory unit 8202, and may further include a read only memory unit (ROM) 8203.

The storage unit 820 may also include a program/utility 8204 having a set (at least one) of program modules 8205, such program modules 8205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.

Bus 830 may be any one or more of several types of bus structures including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

The blockchain gateway server 401 may also communicate with one or more external devices 700 (e.g., keyboard, pointing device, bluetooth device, etc.), with one or more devices that enable a user to interact with the blockchain gateway server 401, and/or with any devices (e.g., router, modem, etc.) that enable the blockchain gateway server 401 to communicate with one or more other computing devices. Such communication may occur via an input/output (I/O) interface 650. Also, the blockchain gateway server 401 may also communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) through a network adapter 860. As shown, a network adapter 860 communicates with the other modules of the blockchain gateway server 401 over a bus 830. It should be appreciated that although not shown in the figures, other hardware and/or software modules may be used in conjunction with blockchain gateway server 401, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, to name a few.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

In an exemplary embodiment of the present disclosure, there is also provided a computer program medium having stored thereon computer readable instructions which, when executed by a processor of a computer, cause the computer to perform the method described in the above method embodiment section.

According to an embodiment of the present disclosure, there is also provided a program product for implementing the method in the above method embodiment, which may employ a portable compact disc read only memory (CD-ROM) and include program code, and may be run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited in this respect, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

A computer readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., through the internet using an internet service provider).

It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.

Moreover, although the steps of the methods of the present disclosure are depicted in the drawings in a particular order, this does not require or imply that these steps must be performed in this particular order, or that all of the depicted steps must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions, etc.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, and may also be implemented by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice in the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

Claims

1. An information processing method in invoicing is characterized by comprising the following steps:

receiving an invoice issuing request, wherein the invoice issuing request comprises invoice information and issue event invoice transfer information;

recording the invoice information and the issue event invoice transfer information in a block chain;

when the invoice information and the issue event invoice transfer information in the found event block are respectively consistent with the invoice information in the invoice issuing request and the issue event invoice transfer information, sending a response for allowing invoicing;

the invoicing request also contains billing unit information,

when the invoice information and the issue event invoice transfer information in the found event block are respectively consistent with the invoice information in the invoice issuing request and the issue event invoice transfer information, sending a response allowing invoicing, including:

inquiring the attribution party information of the invoice when the invoice information and the issue event invoice transfer information in the searched event block are respectively consistent with the invoice information in the invoice issuing request and the issue event invoice transfer information;

and when the inquired information of the attribution party is consistent with the information of the billing unit, sending a response of allowing billing.

2. The method of claim 1, wherein after sending the response that allows billing, the method further comprises:

receiving an invoicing transfer request, wherein the invoicing transfer request comprises invoice information and invoicing event invoice transfer information, and the invoicing event invoice transfer information comprises invoice transferring-in party information;

recording the invoice information and invoice transfer information of the invoicing event on a block chain;

and replacing the attribution party information in the invoice attribution table corresponding to the invoice identification with the invoice transfer party information in the invoice transfer information of the invoicing event.

3. The method according to claim 2, wherein the recording the invoice information, invoicing event invoice transfer information on a blockchain comprises:

performing summary operation on the invoice information and the invoice transfer information of the invoicing event to generate a summary value of a block main body of the event block for invoicing;

taking the block main body summary value of the event block for making an invoice and the summary value of the last block before the event block for making an invoice is not recorded on the block chain together as at least one part of the block head of the event block for making an invoice;

taking the invoice information and invoice transfer information of the invoicing event as a block main body of the event block for invoicing;

and connecting the block head and the block main body in series to be used as an event block for billing so as to record in a block chain.

4. The method according to claim 1, wherein the identification of the event block issuing the invoice is a block body summary value generated by performing a summary operation on a block body including invoice information and invoice issue event invoice transfer information, and the event block issuing the invoice comprises:

a summary value of a block body of the event block issuing the invoice as at least a part of a block header of the event block issuing the invoice and a summary value of a last block before the event block issuing the invoice is not recorded on the block chain;

the invoice information and invoice issue event invoice transfer information as a block body of the event block issuing the invoice.

5. The method of claim 1, wherein the invoice information includes an invoice identification, the issue event invoice transfer information includes invoice transfer-in information,

the inquiring of the information of the attribution party of the invoice comprises the following steps:

determining an event block with the latest recording time in the event blocks with the invoice identification in the invoicing request on the block chain;

and transferring the invoice in the determined event block into party information as attribution party information of the invoice.

6. The method according to claim 2, wherein the replacing the attribution party information in the invoice attribution table corresponding to the invoice identifier with the invoice turning-in party information in the invoicing event invoice turning-in information comprises:

and replacing attribution party information in an invoice attribution table corresponding to the invoice identifier, which is set outside the blockchain, with the invoice transfer-in party information in the invoicing event invoice transfer information.

7. The method of claim 1, wherein after recording the invoice information, issue event invoice transfer information in a blockchain, the method comprises:

and writing the invoice transfer party information in the issue event invoice transfer information into an invoice attribution table as attribution party information corresponding to the invoice identifier.

8. The method of claim 1, wherein after sending the response that allows billing, the method further comprises:

receiving an invoicing transfer request, wherein the invoicing transfer request comprises invoice information and invoice transfer information of an invoicing event;

and recording the invoice transfer information of the invoicing event in an invoice transfer registration table which is arranged outside the blockchain and corresponds to the invoice identification.

9. The method of claim 1, wherein after recording the invoice information, issue event invoice transfer information in a blockchain, the method further comprises:

and recording the issue event invoice transfer information in an invoice transfer registration table which is arranged outside the blockchain and corresponds to an invoice identifier.

10. The method of claim 9, wherein the invoice information includes an invoice identification, the issue event invoice transfer information includes invoice transfer-in information,

the inquiring of the attribution party information of the invoice comprises the following steps:

and inquiring the invoice transfer register table according to the invoice identifier, and taking the invoice transfer party information in the last invoice transfer information of the invoice identifier in the invoice transfer register table as the attribution party information.

11. An information processing apparatus in invoicing, characterized by comprising:

a second receiving unit, configured to receive an invoice issuing request, where the invoice issuing request includes invoice information and issue event invoice transfer information; recording the invoice information and the issue event invoice transfer information in a block chain; receiving an invoice issuing request, wherein the invoice issuing request comprises an identifier of an event block issuing the invoice, invoice information, issue event invoice transfer information and invoice issuing unit information, which are recorded on a block chain;

the second sending unit is used for inquiring the attribution party information of the invoice when the invoice information and the issue event invoice transfer information in the searched event block are respectively consistent with the invoice information in the invoice issuing request and the issue event invoice transfer information; and when the inquired information of the attribution party is consistent with the information of the billing unit, sending a response of allowing billing.

12. A blockchain gateway server, comprising:

a memory storing computer readable instructions;

a processor reading computer readable instructions stored by the memory to perform the method of any of claims 1-10.

13. A computer program medium having computer readable instructions stored thereon which, when executed by a processor of a computer, cause the computer to perform the method of any one of claims 1-10.