WO2017133570A1 - 一种发票抬头信息变更方法、装置和发票管理系统 - Google Patents

一种发票抬头信息变更方法、装置和发票管理系统 Download PDF

Info

Publication number
WO2017133570A1
WO2017133570A1 PCT/CN2017/072406 CN2017072406W WO2017133570A1 WO 2017133570 A1 WO2017133570 A1 WO 2017133570A1 CN 2017072406 W CN2017072406 W CN 2017072406W WO 2017133570 A1 WO2017133570 A1 WO 2017133570A1
Authority
WO
WIPO (PCT)
Prior art keywords
header
information
invoice
new
shadow
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2017/072406
Other languages
English (en)
French (fr)
Inventor
段亚军
王均方
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Publication of WO2017133570A1 publication Critical patent/WO2017133570A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/103—Workflow collaboration or project management

Definitions

  • the present application relates to the field of information processing technologies, and in particular, to a method and device for changing invoice header information, and an invoice management system.
  • embodiments of the present application have been made in order to provide an invoice header change method and a corresponding invoice header change device, and an invoice management system, which overcome the above problems or at least partially solve the above problems.
  • the application discloses a method for changing the invoice header information, including:
  • the shadow header data table includes original header information, new header information, and current change record information
  • the old header information of the invoice is changed to the new header information; and the new header status of the current change record information in the shadow header data table is updated to be valid, and the old header status is invalid.
  • an invoice header information changing device including:
  • a receiving module configured to receive an invoice header information change request submitted by a user
  • a determining module configured to determine, according to a preset rule, whether the change request received by the receiving module needs to be audited
  • a generating module configured to generate, according to the change request, a corresponding shadow header data table, where the shadow header data table includes original header information, new header information, and current change record information, if the determining module determines that the audit is required to be performed;
  • a change module configured to: if the new header information is approved, change the old header information of the invoice to the new header information; correspondingly, the generating module is further configured to update a new header of the current change record information in the shadow header data table. The status is valid and the old header status is invalid.
  • the application also discloses a method for changing the invoice header information, including:
  • the shadow header data table includes original header information, new header information, and current change record information
  • the invoice new header information is restored to the old header information that has been in effect before the change based on the user-submitted revocation change request and the current change record information of the shadow header data table; and
  • the new header state of the current change record information in the shadow header data table is undo, and the old header state is valid.
  • an invoice header information changing device including:
  • a receiving module configured to receive an invoice header information change request submitted by a user
  • a determining module configured to determine, according to a preset rule, whether the change request received by the receiving module needs to be audited
  • a generating module configured to generate, according to the change request, a corresponding shadow header data table, where the shadow header data table includes original header information, new header information, and current change, if the determining module determines that the audit is required to be performed. record information;
  • a searching module configured to search for current change record information of the shadow header data table based on a revocation change request submitted by the user received by the receiving module, if the preset condition is met;
  • a change module configured to restore, according to the current change record information found by the lookup module, the invoice new header information to the old header information that has been in effect before the change; correspondingly, the generating module is further configured to update the The new header state of the current change record information in the shadow header data table is undo, and the old header state is valid.
  • the present application also discloses an invoice management system including the invoice header information changing device as described above.
  • the present application discloses the following technical effects:
  • the embodiment may generate a corresponding shadow header data table based on the change request, and may search for the original header information, the new header information, and the current change record information included in the shadow header data table. Improve the user experience by accurately and efficiently changing the invoice header information.
  • the new header information is restored to the change by the current change record information in the shadow header data table.
  • the old header information that has been in effect before; the flag information of the current change record information in the shadow header data table can be used to effectively find the current state information and the state transition relationship of the new header and the old header, so that the invoice header can be restored to the change.
  • the change of the invoice header information can be performed more accurately and efficiently, and the maintenance and update of the invoice management system is more convenient, and the development difficulty and the maintenance cost are also reduced.
  • FIG. 1 is a flow chart showing the steps of an embodiment of a method for changing invoice header information according to the present application
  • FIG. 2 is a schematic diagram of an embodiment of generating a shadow header data table according to a change request according to the present application
  • FIG. 3 is a flow chart showing the steps of another embodiment of the method for changing invoice header information of the present application.
  • FIG. 4 is a schematic diagram of an embodiment of an invoice header information change process state transition of the present application.
  • FIG. 5 is a schematic diagram of a business process of an embodiment of a method for changing invoice header information according to the present application
  • FIG. 6 is a structural block diagram of an embodiment of an invoice header information changing apparatus of the present application.
  • FIG. 7 is a structural block diagram of another embodiment of an invoice header information changing apparatus of the present application.
  • FIG 8 is an architectural diagram of an embodiment of an invoice management system of the present application.
  • the embodiment of the present application can be applied to an invoice management system, and the user can manage the invoice header information online through the invoice management system.
  • the management of the invoice management system for the invoice header information can be divided into two parts: a new invoice header information management unit and a change invoice header information management unit.
  • the background server performs corresponding processing according to the type of the invoice, and saves it to the database of the invoice management system.
  • invoices can be divided into three types: personal VAT ordinary invoice, enterprise VAT ordinary invoice, and corporate VAT special invoice.
  • personal VAT ordinary invoice For invoice header information that has been saved in the database of the invoice management system, the user may need to change the invoice header information for various reasons.
  • the header items that need to be changed at this time include: personal name or company name.
  • the invoice needs to be changed from the enterprise VAT ordinary invoice to the corporate value-added tax special invoice.
  • the heading items that need to be changed at this time include: tax registration certificate number, registration place address, company registration phone number, bank account information, and the like.
  • Some business scenarios require financial review in the change process.
  • the enterprise VAT ordinary invoice is changed to the enterprise VAT special invoice
  • the corporate VAT special invoice is changed in the name of the head
  • the personal VAT ordinary invoice is changed to the enterprise value added. Tax special invoices, etc.
  • the embodiment may generate a corresponding shadow header data table based on the change request, and may search for the original header information, the new header information, and the current change record information included in the shadow header data table. Improve the user experience by accurately and efficiently changing the invoice header information.
  • the change of the invoice header information can be performed more accurately and efficiently, and the maintenance and update of the invoice management system is more convenient, and the development difficulty and the maintenance cost are also reduced.
  • the process of changing the invoice header information may involve the following states:
  • the system needs to perform a corresponding financial review on the change request submitted by the user, so that the new header is in the pending review state;
  • the operation of canceling the change may be performed, that is, entering the new header revocation state.
  • the old header is set to the valid state by the invoice management system, that is, the invoice header information is restored to the old header information that the invoice has been valid before the user submits the change.
  • a change request submitted by a user fails the financial review, that is, the new header is in a rejected state.
  • the user can modify and submit again according to the prompt of the system, and re-enter the new header to be reviewed; or directly cancel the operation of canceling the change, that is, enter the new header revocation state.
  • a change request submitted by a user passes a financial review, that is, the new header is in a valid state.
  • the old header will be set to the invalid state by the invoice management system, that is, the invoice header information is changed to the new header information.
  • the system directly rejects, it enters the new header failure state, that is, the unavailable state.
  • the old header is neither a valid state nor a failed state, and may be converted to an active state or an intermediate state of the failed state, that is, the old header is in a locked state in the new header pending review state or the new header rejection state.
  • the status of the old header is set to the invalid state by the invoice management system from the locked state, that is, the unavailable state, that is, the invoice header information is changed to the new header information.
  • the status of the old header is set to the active state by the invoice management system when the new header is in the rejected state, and the invoice header information is restored to the old header information.
  • the invoice management system provided by the embodiment of the present application can restore the invoice new header information to the old header information that has been in effect before the change by using the current change record information in the shadow header data table; and can also use the current change record in the shadow header data table.
  • the tag information of the information effectively find the current state information of the new header and the old header and the state transition relationship, so that the invoice header can be restored to an intermediate state or the original state before the change, and real-time data rollback is provided, thereby further Effectively implement error troubleshooting throughout the change process.
  • FIG. 1 a flow chart of steps of an embodiment of a method for changing invoice header information of the present application is shown, which may specifically include the following steps:
  • Step 110 Receive an invoice header information change request submitted by a user
  • Step 120 Determine, according to a preset rule, whether the change request needs to be audited
  • the audit described in the embodiment of the present application refers to a financial audit.
  • certain business scenarios do not require financial review in the change process.
  • the personal or corporate VAT ordinary invoices are filled in with incorrect changes.
  • Some business scenarios require financial review in the change process.
  • the enterprise VAT ordinary invoice is changed to the enterprise VAT special invoice, and the corporate VAT special invoice is changed.
  • the personal VAT ordinary invoice is changed to the enterprise VAT special invoice. Therefore, the preset rule described in the embodiment of the present application is preset in the system according to a specific financial auditing standard, and when determining whether the change request needs to be subjected to the financial review, the judgment may be performed according to the preset rule.
  • Step 130 if a financial review is required, generating a corresponding shadow header data table based on the change request, where the shadow header data table includes original header information, new header information, and current change record information;
  • the current change record information in the shadow header data table includes information related to the change, for example, old header information that has been in effect before the change, current status information of the new header and the old header, and the like.
  • a corresponding shadow header data table 1 is generated according to the change request 1, and the shadow header data table 1 includes at least: original header information, new header information, and current change record. information.
  • a corresponding shadow header data table 2 is generated according to the change request 2
  • the shadow header data table 2 includes at least: original header information, new header information, and current change record information. It can be understood that, if there is a change request n, the corresponding shadow header data table n is generated according to the change request n.
  • Step 140 If the new header information passes the financial review, the old header information of the invoice is changed to the new header information
  • Step 150 Update the new header state of the current change record information in the shadow header data table to be valid, and the old header state to be invalid.
  • the embodiment may generate a corresponding shadow header data table based on the change request, and may search for the original header information, the new header information, and the current change record information included in the shadow header data table. Improve the user experience by accurately and efficiently changing the invoice header information.
  • the change of the invoice header information can be performed more accurately and efficiently, and the maintenance and update of the invoice management system is more convenient, and the development difficulty and the maintenance cost are also reduced.
  • the method may include the following steps:
  • Step 310 Receive an invoice header information change request submitted by a user
  • the original invoice of the invoice needs to be in a valid state in order to carry out the subsequent change process, so it is necessary to determine that the original header of the invoice in the database is in a valid state before entering the change process.
  • the manner of determining the original header of the invoice is not limited in the embodiment of the present invention.
  • Step 320 Determine, according to a preset rule, whether the change request needs to perform a financial review
  • the preset rule described in the embodiment of the present application is preset in the system according to a specific financial auditing standard, and when determining whether the change request needs to be subjected to the financial review, the judgment may be performed according to the preset rule.
  • Step 330 if a financial review is required, generating a corresponding shadow header data table based on the change request, where the shadow header data table includes original header information, new header information, and current change record information;
  • the current change record information in the shadow header data table includes information related to the change, for example, old header information that has been in effect before the change, current status information of the new header and the old header, and the like.
  • a corresponding shadow header data table 1 is generated according to the change request 1, and the shadow header data table 1 includes at least: original header information, new header information, and current change record. information.
  • a corresponding shadow header data table 2 is generated according to the change request 2
  • the shadow header data table 2 includes at least: original header information, new header information, and current change record information. It can be understood that, if there is a change request n, the corresponding shadow header data table n is generated according to the change request n.
  • the current change record information of the shadow header data table further includes tag information to indicate a state transition relationship between the new header and the old header.
  • tag information to indicate a state transition relationship between the new header and the old header.
  • a flag of a state transition relationship between the new header and the old header is implemented by setting an identifier or a tag code or the like.
  • Step 340 if the new header information passes the financial review, the old header information of the invoice is changed to the new header information;
  • Step 350 Update a new header state of the current change record information in the shadow header data table to be valid, and the old header state is invalid.
  • Step 360 If the preset condition is met, the new header information of the invoice is restored to the old header information that has been in effect before the change based on the revocation change request submitted by the user and the current change record information of the shadow header data table;
  • the preset condition is: the new header information fails the review; and the method further includes: updating the shadow when the new header information fails the review The new header status of the current change record information in the header data table is rejected, and the old header status is locked.
  • the preset condition is: the new header information is in a pending state; and the method further includes: updating the shadow when the new header information is in a pending state The new header status of the current change record information in the header data table is pending review, and the old header status is locked.
  • Step 370 Update a new header state of the current change record information in the shadow header data table to be revoked, and the old header state is valid.
  • the method may further include:
  • step 380 if the financial review is not required, the invoice old header information is changed to the new header information.
  • the embodiment may generate a corresponding shadow header data table based on the change request, and may search for the original header information, the new header information, and the current change record information included in the shadow header data table. Improve the user experience by accurately and efficiently changing the invoice header information.
  • the new header information is restored to the change by the current change record information in the shadow header data table.
  • the old header information that has been in effect before; the flag information of the current change record information in the shadow header data table can be used to effectively find the current state information and the state transition relationship of the new header and the old header, so that the invoice header can be restored to the change.
  • the change of the invoice header information can be performed more accurately and efficiently, and the maintenance and update of the invoice management system is more convenient, and the development difficulty and the maintenance cost are also reduced.
  • FIG. 4 there is shown a schematic diagram of an embodiment of an invoice header information change flow state transition of the present application, which includes the entire change flow before the change, the change process, and the change end.
  • the entire change process includes: original header is valid; new header is pending review, old header lock; new header rejection, old header lock; new header undo, old header is valid; new header is valid, old header is invalid; The new header fails, with a total of six transitions between states.
  • the shadow header data table includes original header information, new header information, and current change record information.
  • the current change record information in the shadow header data table includes information related to the change, for example, old header information that has been in effect before the change, current status information of the new header and the old header, and is used to indicate the state transition of the new header and the old header. Tag information of the relationship, etc.
  • the current change record information includes indication information used to indicate the state of being transferred from the original header to the state of the new header to be reviewed, and the old header lock; if the new header information does not require financial review in the change process
  • the state in which the original header is valid is directly updated to the state in which the new header is valid and the old header is invalid, and the generation of the shadow header data table is not accompanied.
  • the generated shadow header data table includes original header information, new header information, old header information that has been in effect before the change, current change record information, current header information, and current status information of the old header.
  • the current change record information includes indication information used to indicate a status of a new header to be reviewed, an old header lock state transition to a new header rejection, and an old header lock;
  • the generated shadow header data table includes the original header information, the new header information, Current change record information.
  • the current change record information includes indication information indicating that the status of the new header to be reviewed, the old header lock is transferred to the new header, and the old header is invalid;
  • the shadow header data table includes original header information, new header information, and current change record information.
  • the current change record information includes indication information indicating that the state of the new header is pending review, the state of the old header lock is transferred to the new header undo, and the old header is valid.
  • the generated shadow header data table includes original header information, new header information, and current change record information.
  • the current change record information includes indication information for indicating a state of being rejected by the new head, the state of the old head lock is transferred back to the new head to be audited, and the old head lock is locked;
  • the operation of this change can be revoked, so the new lookup
  • the state of rejection or old header lock is transferred to the state where the new header is revoked and the old header is valid; at this time, the generated shadow header data table includes original header information, new header information, and current change record information.
  • the current change record information includes indication information for indicating a state of being rejected by the new head, the state of the old head lock is transferred to the new head undo, and the old head is valid.
  • the system can select a head from the failed head to edit, and then enter the change process again after it takes effect.
  • the scene of failure is automatically caused by the system, such as major changes in the system, it may cause the user's previous invoices of all invoices to be invalid.
  • the user may need the previous header information. Therefore, in a preferred embodiment, the user may be provided with a way to select a failed head-up from the failed heads for continued operation. For specific applications, all of the user's failed headers can be listed, and then the user selects one for subsequent operations.
  • the embodiment may generate a corresponding shadow header data table based on the change request, and may search for the original header information, the new header information, and the current change record information included in the shadow header data table. Improve the user experience by accurately and efficiently changing the invoice header information.
  • the new header information is restored to the change by the current change record information in the shadow header data table.
  • the old header information that has been in effect before; the flag information of the current change record information in the shadow header data table can be used to effectively find the current state information and the state transition relationship of the new header and the old header, so that the invoice header can be restored to the change.
  • the invoice needs to be changed from the enterprise VAT ordinary invoice to the corporate value-added tax special invoice.
  • the heads that need to be changed at this time include: tax registration number, Registered place address, company registration phone number, bank account information, etc.
  • the user enters the invoice management interface, and obtains the invoice header information list by calling the interface to retrieve the database information on the server.
  • the user selects the type of change, that is, the enterprise VAT ordinary invoice is changed to the enterprise VAT special invoice; then, since it is changed from the enterprise VAT ordinary invoice to the enterprise VAT special invoice, it is judged that the type of the issuing does not need to be changed; After confirming that the name of the heading needs to be changed, if it is further judged that the name of the head is not filled incorrectly, the user submits the registration change information; if the system judges that it is a special invoice for the company's value-added tax, the user is required to submit the header and other information of the special invoice for the company's value-added tax, and submit the business change. Prove that the system conducts financial audits;
  • the system updates the current change record information in the generated shadow header data table to the new header rejection and the old header lock state.
  • the system can click the undo button.
  • the change operation will be revoked.
  • the system will update the status of the new header and the old header in the current change record information in the shadow header data table, and record the state of the new header rejection and the old header lock to the new header.
  • the status change relationship of the revocation and the old header is valid; at the same time, the system restores the new header information of the invoice to the old header information that has been in effect before the change according to the current change record information in the shadow header data table.
  • the user can re-submit and re-submit the financial review according to the system prompts; if the financial review is passed, the new header submitted is valid; the change process is ended.
  • the embodiment may generate a corresponding shadow header data table based on the change request, and may search for the original header information, the new header information, and the current change record information included in the shadow header data table. Improve the user experience by accurately and efficiently changing the invoice header information.
  • the new header information is restored to the change by the current change record information in the shadow header data table.
  • the old header information that has been in effect before; the flag information of the current change record information in the shadow header data table can be used to effectively find the current state information and the state transition relationship of the new header and the old header, so that the invoice header can be restored to the change.
  • the change of the invoice header information can be performed more accurately and efficiently, and the maintenance and update of the invoice management system is more convenient, and the development difficulty and the maintenance cost are also reduced.
  • FIG. 6 a structural block diagram of an embodiment of an invoice header information changing apparatus of the present application is shown, which may specifically include the following modules:
  • the receiving module 610 is configured to receive an invoice header information change request submitted by the user;
  • the determining module 620 is configured to determine, according to the preset rule, whether the change request received by the receiving module needs to perform a financial review; wherein, in another embodiment of the present application, the determining module 620 may further be configured to determine that the original header is in Valid state.
  • the preset rule described in the embodiment of the present application is preset in the system according to a specific financial auditing standard, and when determining whether the change request needs to be subjected to the financial review, the judgment may be performed according to the preset rule.
  • the generating module 630 is configured to generate, according to the change request, a corresponding shadow header data table, where the shadow header data table includes original header information, new header information, and current change record, if the determining module 620 determines that a financial review is required. information;
  • the current change record information in the shadow header data table includes information related to the change, for example, old header information that has been in effect before the change, current status information of the new header and the old header, and the like.
  • the change module 640 is configured to change the old header information of the invoice to the new header information if the new header information passes the financial review.
  • the generating module 630 is further configured to update a new header state of the current change record information in the shadow header data table to be valid, and the old header state to be invalid.
  • the embodiment may generate a corresponding shadow header data table based on the change request, and may search for the original header information, the new header information, and the current change record information included in the shadow header data table. Improve the user experience by accurately and efficiently changing the invoice header information.
  • the change of the invoice header information can be performed more accurately and efficiently, and the maintenance and update of the invoice management system is more convenient, and the development difficulty and the maintenance cost are also reduced.
  • FIG. 7 a structural block diagram of another embodiment of an invoice header information changing apparatus of the present application is shown, which may specifically include the following modules:
  • the receiving module 710 is configured to receive an invoice header information change request submitted by the user
  • the determining module 720 is configured to determine, according to the preset rule, whether the change request received by the receiving module needs to perform a financial review; wherein, in another embodiment of the present application, the determining module 720 is further configured to determine that the original header is in Valid state. It can be understood that the invoice original header needs to be in a valid state in order to carry out the subsequent change process, so it is necessary to determine that the original header state is valid before entering the change process. As for the specific manner of determining the original header state of the invoice, the embodiment of the present invention is not limited.
  • the preset rule described in the embodiment of the present application is preset in the system according to a specific financial auditing standard, and when determining whether the change request needs to be subjected to the financial review, the judgment may be performed according to the preset rule.
  • the generating module 730 is configured to generate, according to the change request, a corresponding shadow header data table, where the shadow header data table includes original header information, new header information, and current change record information, if the determining module 720 determines that the audit is required to be performed. ;
  • the current change record information in the shadow header data table includes information related to the change, for example, old header information that has been in effect before the change, current status information of the new header and the old header, to indicate the new header and Mark information of the old headed state transition relationship, etc.
  • the generating module 730 may generate a corresponding shadow header data table 1 according to the change request 1, and the shadow header data table 1 includes at least: original header information and new header information. , current change record information. If there is a change request 2, the generating module 730 may further generate a corresponding shadow header data table 2 according to the change request 2, the shadow header data table 2 including at least: original header information, new header information, and current change record information. Understandably, and so on, if there are change requests next n, the generation module 730 can also generate a corresponding shadow header data table n according to the change request n.
  • the change module 740 is configured to: if the new header information passes the financial review, change the old header information of the invoice to the new header information; correspondingly, the generating module 730 is further configured to update the current change record information in the shadow header data table.
  • the new header status is valid and the old header status is invalid.
  • the current change record information of the shadow header data table includes tag information to indicate a state transition relationship between the new header and the old header.
  • the generation module 730 implements a flag of a state transition relationship between the new header and the old header by setting an identifier or a tag code or the like in the shadow header data table.
  • the specific implementation manner in which the generating module 730 records the current change record information in the shadow header data table is not limited to the implementation manner of the embodiment of the present application, and may be various, as long as it can be used to indicate a new head. The state transition relationship with the old head is sufficient. For this reason, the embodiment of the present application does not limit this.
  • the searching module 750 is configured to search for the current change record information of the shadow header data table based on the undo change request submitted by the user received by the receiving module 710, if the preset condition is met;
  • the change module 740 is further configured to restore, according to the current change record information found by the lookup module 740, the invoice new header information to the old header information that has been in effect before the change; correspondingly,
  • the generating module 730 is further configured to update a new header state of the current change record information in the shadow header data table to be undoed, and the old header state is valid.
  • the preset condition is: the new header information is in a pending state;
  • the generating module 730 is further configured to: when the new header information is in a state to be audited, update a new header state of the shadow header data table to be audited, and the old header state is locked;
  • the preset condition is that the new header information fails the financial review
  • the generating module 730 is further configured to: when the new header information fails to pass the review, update the new header state of the shadow header data table to be rejected, and the old header state to be locked.
  • the change module 740 is further configured to: if the determining module 720 determines that the financial review is not required, change the invoice old header information to the new header information.
  • the embodiment of the present application may further include a saving module 760, configured to save the new header information and the shadow header data table generated during the change process in the database after the invoice header information change process ends.
  • a saving module 760 configured to save the new header information and the shadow header data table generated during the change process in the database after the invoice header information change process ends.
  • the embodiment may generate a corresponding shadow header data table based on the change request, and may search for the original header information, the new header information, and the current change record information included in the shadow header data table. Improve the user experience by accurately and efficiently changing the invoice header information.
  • the new header information of the invoice is restored to the old header information that has been in effect before the change by using the current change record information in the shadow header data table; and the mark information of the record information currently changed in the shadow header data table may also be Effectively find the current status information of the new header and the old header and the state transition relationship, so that the invoice header can be restored to an intermediate state or the original state before the change, and real-time data rollback can be provided, thereby implementing the entire change more effectively. Troubleshooting during the process.
  • the change of the invoice header information can be performed more accurately and efficiently, and the maintenance and update of the invoice management system is more convenient, and the development difficulty and the maintenance cost are also reduced.
  • the invoice management system 800 includes an invoice header information changing device 810 and a database 820.
  • the specific structure of the invoice header information changing device 810 is described. See the above embodiment, and details are not described herein again.
  • the invoice management information can be managed by the user through the client accessing the invoice management system 800 on the Invoice Management Center server. Specifically, after receiving the change request of the user invoice header information, the invoice header information changing means 810 of the invoice management system 800 gives corresponding processing based on the type of the invoice based on the background server, and saves the related data information to the invoice management system 800. In the database 820.
  • invoice management system of the embodiment of the present application can be applied to the invoice management center server or the invoice management platform, which is not limited in this embodiment of the present application.
  • the embodiment may generate a corresponding shadow header data table based on the change request, and may search for the original header information, the new header information, and the current change record information included in the shadow header data table. Improve the user experience by accurately and efficiently changing the invoice header information.
  • the new header information is restored to the change by the current change record information in the shadow header data table.
  • the old header information that has been in effect before; the flag information of the current change record information in the shadow header data table can be used to effectively find the current state information and the state transition relationship of the new header and the old header, so that the invoice header can be restored to the change.
  • the change of the invoice header information can be performed more accurately and efficiently, and Easy maintenance and update of the invoice management system also reduces development difficulty and maintenance costs.
  • the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • embodiments of the embodiments of the present application can be provided as a method, apparatus, or computer program product. Therefore, the embodiments of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Moreover, embodiments of the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD@ROM, optical storage, etc.) including computer usable program code.
  • computer-usable storage media including but not limited to disk storage, CD@ROM, optical storage, etc.
  • the computer device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • the memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory.
  • RAM random access memory
  • ROM read only memory
  • Memory is an example of a computer readable medium.
  • Computer readable media includes both permanent and non-persistent, removable and non-removable media.
  • Information storage can be implemented by any method or technology. The information can be computer readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, read-only optical read-only memory (CD@ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
  • computer readable media does not include non-persistent computer readable media, such as modulated data signals and carrier waves.
  • Embodiments of the present application are described with reference to flowcharts and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the present application. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG.
  • These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing terminal device to produce a machine such that instructions are executed by a processor of a computer or other programmable data processing terminal device
  • Means are provided for implementing the functions specified in one or more of the flow or in one or more blocks of the flow chart.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the instruction device implements the functions specified in one or more blocks of the flowchart or in a flow or block of the flowchart.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Human Resources & Organizations (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Data Mining & Analysis (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请实施例提供一种发票抬头信息变更方法、装置和发票管理系统。所述方法包括：接收用户提交的发票抬头信息变更请求；基于预置规则确定所述变更请求是否需要进行审核；如果需要进行审核，则基于变更请求生成对应的影子抬头数据表，其中，所述影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息；若新抬头信息通过审核，则将发票旧抬头信息变更为新抬头信息；以及更新所述影子抬头数据表中当前变更记录信息的新抬头状态为有效、旧抬头状态为失效。本申请实施例可以更准确高效的进行发票抬头信息的变更、提高用户体验。

Description

一种发票抬头信息变更方法、装置和发票管理系统
本申请要求2016年02月05日递交的申请号为201610080755.6、发明名称为“一种发票抬头信息变更方法、装置和发票管理系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及信息处理技术领域，特别是涉及一种发票抬头信息变更方法、装置和发票管理系统。
背景技术
在电子商务应用广泛普及的今天，随着信息技术的快速发展，信息呈现出爆发式的增长，人们对如何能更高效的处理信息的要求也越来越高。例如，在发票管理中心，用户可以对开具发票的信息进行管理。对于系统内已经生效的发票抬头信息，用户可能基于各种原因需要对发票抬头信息进行变更。但由于不同发票类型的财务审核要求的严格程度是不同的，所以在变更发票抬头信息流程中允许变更的项目也有所不同，变更的抬头信息是否需要财务审核的情况也不同。另外，由于发票抬头在变更流程中所处的状态也有多种情况，从而造成多种状态之间的相互转移关系也比较复杂。如果用户欲对已经生效的某种类型的发票抬头信息进行变更，并且变更的次数可能还不止一次；那么，当用户在对发票抬头信息进行若干次变更后，如因遇到某种情况而需要终止本次变更流程，现有技术还无法提供撤销变更操作的处理。因此，在用户进行发票抬头信息变更时，现有技术的缺陷会给用户带来诸多不变。
因此，如何更准确、高效地进行发票抬头信息的变更，成为亟需本领域技术人员解决的技术问题。
发明内容
鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种发票抬头信息变更方法和相应的一种发票抬头信息变更装置，以及一种发票管理系统。
本申请公开了一种发票抬头信息变更方法，包括：
接收用户提交的发票抬头信息变更请求；
基于预置规则确定所述变更请求是否需要进行审核；
如果需要进行审核，则基于变更请求生成对应的影子抬头数据表，其中，所述影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息；
若新抬头信息通过审核，则将发票旧抬头信息变更为新抬头信息；以及，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为有效、旧抬头状态为失效。
相应的，本申请公开了一种发票抬头信息变更装置，包括：
接收模块，用于接收用户提交的发票抬头信息变更请求；
确定模块，用于基于预置规则确定所述接收模块接收到的变更请求是否需要进行审核；
生成模块，用于若所述确定模块确定需要进行审核，则基于变更请求生成对应的影子抬头数据表，其中，所述影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息；
变更模块，用于若新抬头信息通过审核，则将发票旧抬头信息变更为新抬头信息；相应的，所述生成模块，还用于更新所述影子抬头数据表中当前变更记录信息的新抬头状态为有效、旧抬头状态为失效。
本申请还公开了一种发票抬头信息变更方法，包括：
接收用户提交的发票抬头信息变更请求；
基于预置规则确定所述变更请求是否需要进行审核；
如果需要进行审核，则基于变更请求生成对应的影子抬头数据表，其中，所述影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息；
在符合预置条件的情况下，基于用户提交的撤销变更请求和所述影子抬头数据表的当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；以及，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为撤销、旧抬头状态为有效。
相应的，本申请公开了一种发票抬头信息变更装置，包括：
接收模块，用于接收用户提交的发票抬头信息变更请求；
确定模块，用于基于预置规则确定所述接收模块接收到的变更请求是否需要进行审核；
生成模块，用于若所述确定模块确定需要进行审核，则基于变更请求生成对应的影子抬头数据表，其中，所述影子抬头数据表包括原始抬头信息、新抬头信息、当前变更 记录信息；
查找模块，用于在符合预置条件的情况下，基于所述接收模块接收的用户提交的撤销变更请求，查找所述影子抬头数据表的当前变更记录信息；
变更模块，用于基于所述查找模块查找到的所述当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；相应的，所述生成模块，还用于更新所述影子抬头数据表中当前变更记录信息的新抬头状态为撤销、旧抬头状态为有效。
本申请还公开了一种发票管理系统，包括如上所述的发票抬头信息变更装置。
根据本申请提供的具体实施例，本申请公开了以下技术效果：
本申请实施例可以在变更发票抬头信息过程中，基于变更请求生成对应的影子抬头数据表，可以通过查找该影子抬头数据表中所包括的原始抬头信息、新抬头信息、当前变更记录信息，更准确有效的进行发票抬头信息的变更，从而提高用户体验。
进一步的，当用户在对发票抬头信息进行若干次变更后，如因遇到某种情况而需要执行撤销操作时，通过该影子抬头数据表中当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；还可以通过该影子抬头数据表中当前变更记录信息的标记信息，有效的查找新抬头和旧抬头的当前状态信息以及状态转移关系，从而可以将发票抬头恢复到变更前的某个中间状态或原始状态，并提供实时的数据回滚，进而更加有效的实现整个变更过程中的错误排查。
此外，通过本申请实施例，可以更准确高效的进行发票抬头信息的变更，并且更加易于发票管理系统的维护和更新，也降低开发难度和维护成本。
当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请的一种发票抬头信息变更方法实施例的步骤流程图；
图2是本申请的一种根据变更请求生成影子抬头数据表的实施例原理图；
图3是本申请的另一种发票抬头信息变更方法实施例的步骤流程图；
图4是本申请的一种发票抬头信息变更流程状态转移的实施例示意图；
图5是本申请的一种发票抬头信息变更方法实施例的业务流程示意图；
图6是本申请的一种发票抬头信息变更装置实施例的结构框图；
图7是本申请的另一种发票抬头信息变更装置实施例的结构框图；
图8是本申请的一种发票管理系统实施例的架构图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。
为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。
本申请实施例可以应用在一种发票管理系统中，用户可以通过该发票管理系统在线对发票抬头信息进行管理。其中，该发票管理系统针对发票抬头信息的管理可以分为新增发票抬头信息管理单元和变更发票抬头信息管理单元两个部分。
具体而言，新增发票抬头信息管理单元收到用户新增发票抬头信息的请求后，基于后台服务器根据发票的类型给予相应的处理，保存到发票管理系统的数据库中。
通常而言，发票的类型可以分为：个人增值税普通发票、企业增值税普通发票、以及企业增值税专用发票这三种。对于在发票管理系统的数据库内已经保存生效的发票抬头信息，用户可能基于各种原因需要对发票抬头信息进行变更。
例如：抬头填写错误，需要将填写错误的旧抬头变更成新抬头。一般的，此时需要变更的抬头项目包括：个人姓名或企业名称。
再例如，企业从小规模纳税人变更为一般纳税人，则发票需要从企业增值税普通发票变更为企业增值税专用发票。一般的，此时需要变更的抬头项目包括：税务登记证号、注册场所地址、公司注册电话、银行账户信息等。
又例如，企业名称发生变化后，也需要变更新抬头。
然而，由于不同发票类型的财务审核要求的严格程度是不同的，所以在变更发票抬头信息流程中允许变更的项目也有所不同，变更的抬头信息是否需要财务审核的情况也不同。
在实际应用中，某些业务场景在变更流程中是不需要进行财务审核的，例如，个人 或者企业增值税普通发票的抬头填写错误的变更等。
而某些业务场景在变更流程中是需要进行财务审核的，例如，企业增值税普通发票变更为企业增值税专用发票，企业增值税专用发票的抬头名称变更，个人增值税普通发票变更为企业增值税专用发票等。
本申请实施例可以在变更发票抬头信息过程中，基于变更请求生成对应的影子抬头数据表，可以通过查找该影子抬头数据表中所包括的原始抬头信息、新抬头信息、当前变更记录信息，更准确有效的进行发票抬头信息的变更，从而提高用户体验。
通过本申请实施例，可以更准确高效的进行发票抬头信息的变更，并且更加易于发票管理系统的维护和更新，也降低开发难度和维护成本。
本发明实施例中，变更发票抬头信息的流程可能涉及以下状态：
A、新抬头待审核状态
例如，用户欲将系统里已经保存生效的个人增值税普通发票变更为企业增值税专用发票，则系统需要对用户提交的变更请求进行相应的财务审核，这样新抬头处于待审核状态；
B、新抬头撤销状态
例如，在待审核状态下，如果用户想终止本次变更流程，则可以执行撤销本次变更的操作，即进入新抬头撤销状态。
在新抬头处于撤销状态的情况下，旧抬头会被发票管理系统设置为有效状态，即将发票抬头信息恢复至用户提交变更前的该发票已经生效的旧抬头信息。
C、新抬头拒绝状态
例如，用户提交的变更请求未通过财务审核，即新抬头处于拒绝状态。
此时，用户可以依据系统的提示修改后再次提交，重新进入新抬头待审核状态；也可以直接执行撤销本次变更的操作，即进入新抬头撤销状态。
D、新抬头有效状态
例如，用户提交的变更请求通过财务审核，即新抬头处于有效状态。
在新抬头处于有效状态的情况下，旧抬头会被发票管理系统设置为失效状态，即将发票抬头信息变更为新抬头信息。
E、新抬头失效状态
例如，在新抬头有效状态或新抬头撤销状态下，如果系统直接驳回，即进入新抬头失效状态，即不可用状态。
F、旧抬头锁定状态
例如，旧抬头既不是有效状态也不是失效状态，并且之后可能转变成有效状态或者失效状态的一种中间状态，即在新抬头待审核状态或新抬头拒绝状态下，旧抬头处于锁定状态。
G、旧抬头失效状态
例如，当新抬头信息通过审核，则在新抬头处于有效状态下，旧抬头的状态会被发票管理系统由锁定状态设置为失效状态，即不可用状态，即将发票抬头信息变更为新抬头信息。
H、旧抬头有效状态
例如，当新抬头信息未通过审核，则在新抬头处于拒绝状态下，旧抬头的状态会被发票管理系统由锁定状态设置为有效状态，即将发票抬头信息恢复为旧抬头信息。
因此，发票抬头信息在变更流程中所处的状态会有多种情况，而这些状态并不是固定不变的，而是随着修改情况以及财务审核的进展而相互转换。因此，如果用户欲对已经生效的某种类型的发票抬头信息进行变更，那么，当用户在对发票抬头信息进行若干次变更后，如因遇到某种情况而需要执行撤销变更的操作时，本申请实施例提供的发票管理系统可以通过该影子抬头数据表中当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；还可以通过该影子抬头数据表中当前变更记录信息的标记信息，有效的查找新抬头和旧抬头的当前状态信息以及状态转移关系，从而可以将发票抬头恢复到变更前的某个中间状态或原始状态，并提供实时的数据回滚，进而更加有效的实现整个变更过程中的错误排查。
实施例一
参照图1，示出了本申请的一种发票抬头信息变更方法实施例的步骤流程图，具体可以包括如下步骤：
步骤110，接收用户提交的发票抬头信息变更请求；
步骤120，基于预置规则确定所述变更请求是否需要进行审核；
可以理解的是，本申请实施例所述的审核是指财务审核。在实际应用中，某些业务场景在变更流程中是不需要进行财务审核的，例如，个人或者企业增值税普通发票的抬头填写错误的变更等。而某些业务场景在变更流程中是需要进行财务审核的，例如，企业增值税普通发票变更为企业增值税专用发票，企业增值税专用发票的抬头名称变更， 个人增值税普通发票变更为企业增值税专用发票等。因此，本申请实施例所述的预置规则，是根据具体的财务审核标准预先设置在系统内的，在确定变更请求是否需要进行财务审核时，就依照该预置规则进行判断即可。
步骤130，如果需要进行财务审核，则基于变更请求生成对应的影子抬头数据表，其中，所述影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息；
需要说明的是，所述影子抬头数据表中当前变更记录信息包括与变更相关的信息，例如，变更前已经生效的旧抬头信息，新抬头和旧抬头的当前状态信息等。
优选的，在本申请实施例中，可以如图2所示，根据变更请求1生成对应的影子抬头数据表1，该影子抬头数据表1至少包括：原始抬头信息、新抬头信息、当前变更记录信息。如果接下来还有变更请求2，则根据变更请求2生成对应的影子抬头数据表2，该影子抬头数据表2至少包括：原始抬头信息、新抬头信息、当前变更记录信息。可以理解的是，以此类推，如果接下来还有变更请求n，则根据变更请求n生成对应的影子抬头数据表n。
步骤140，若新抬头信息通过财务审核，则将发票旧抬头信息变更为新抬头信息；
步骤150，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为有效、旧抬头状态为失效。
可以理解的是，在本申请实施例中，可以如图2所示，发票抬头信息变更流程结束后，新抬头信息和变更过程中生成的影子抬头数据表都会在数据库中保存。
本申请实施例可以在变更发票抬头信息过程中，基于变更请求生成对应的影子抬头数据表，可以通过查找该影子抬头数据表中所包括的原始抬头信息、新抬头信息、当前变更记录信息，更准确有效的进行发票抬头信息的变更，从而提高用户体验。此外，通过本申请实施例，可以更准确高效的进行发票抬头信息的变更，并且更加易于发票管理系统的维护和更新，也降低开发难度和维护成本。
实施例二
参照图3，示出了本申请的另一种发票抬头信息变更方法实施例的步骤流程图，具体可以包括如下步骤：
步骤310，接收用户提交的发票抬头信息变更请求；
需要说明的是，发票原始抬头需要处于有效状态才能进行后续的变更流程，故在进入变更流程之前需要确定数据库内发票原始抬头的状态为有效状态。至于具体采用什么 方式判定发票原始抬头的状态，本发明实施例不做限制。
步骤320，基于预置规则确定所述变更请求是否需要进行财务审核；
可以理解的是，在实际应用中，某些业务场景在变更流程中是不需要进行财务审核的，例如，个人或者企业增值税普通发票的抬头填写错误的变更等。而某些业务场景在变更流程中是需要进行财务审核的，例如，企业增值税普通发票变更为企业增值税专用发票，企业增值税专用发票的抬头名称变更，个人增值税普通发票变更为企业增值税专用发票等。因此，本申请实施例所述的预置规则，是根据具体的财务审核标准预先设置在系统内的，在确定变更请求是否需要进行财务审核时，就依照该预置规则进行判断即可。
步骤330，如果需要进行财务审核，则基于变更请求生成对应的影子抬头数据表，其中，所述影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息；
需要说明的是，所述影子抬头数据表中当前变更记录信息包括与变更相关的信息，例如，变更前已经生效的旧抬头信息，新抬头和旧抬头的当前状态信息等。
优选的，在本申请实施例中，可以如图2所示，根据变更请求1生成对应的影子抬头数据表1，该影子抬头数据表1至少包括：原始抬头信息、新抬头信息、当前变更记录信息。如果接下来还有变更请求2，则根据变更请求2生成对应的影子抬头数据表2，该影子抬头数据表2至少包括：原始抬头信息、新抬头信息、当前变更记录信息。可以理解的是，以此类推，如果接下来还有变更请求n，则根据变更请求n生成对应的影子抬头数据表n。
优选的，在本申请另一优选的实施例中，所述影子抬头数据表的当前变更记录信息还包括标记信息，用以指示新抬头和旧抬头的状态转移关系。例如，在所述影子抬头数据表中通过设置标示符或标记代码等来实现新抬头和旧抬头的状态转移关系的标记。可以理解的是，在所述影子抬头数据表中记录当前变更记录信息的具体实现方式并不局限于本申请实施例的实现方式，还可以有多种，只要能够用来指示新抬头和旧抬头的状态转移关系即可，为此，本申请实施例对此不做限制。
步骤340，若新抬头信息通过财务审核，则将发票旧抬头信息变更为新抬头信息；
步骤350，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为有效、旧抬头状态为失效；
步骤360，在符合预置条件的情况下，基于用户提交的撤销变更请求和所述影子抬头数据表的当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；
优选的，在本申请的一个实施例中，所述预置条件为：所述新抬头信息未通过审核；则所述方法还包括：当所述新抬头信息未通过审核时，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为拒绝、旧抬头状态为锁定。
在本申请的另一个实施例中，所述预置条件为：所述新抬头信息处于待审核状态；则所述方法还包括：当所述新抬头信息处于待审核状态时，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为待审核、旧抬头状态为锁定。
步骤370，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为撤销、旧抬头状态为有效。
优选的，在本申请实施例中，还可以包括：
步骤380，如果不需要进行财务审核，则将发票旧抬头信息变更为新抬头信息。
可以理解的是，在本申请实施例中，可以如图2所示，发票抬头信息变更流程结束后，新抬头信息和变更过程中生成的影子抬头数据表都会在数据库中保存。
本申请实施例可以在变更发票抬头信息过程中，基于变更请求生成对应的影子抬头数据表，可以通过查找该影子抬头数据表中所包括的原始抬头信息、新抬头信息、当前变更记录信息，更准确有效的进行发票抬头信息的变更，从而提高用户体验。
进一步的，当用户在对发票抬头信息进行若干次变更后，如因遇到某种情况而需要执行撤销操作时，通过该影子抬头数据表中当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；还可以通过该影子抬头数据表中当前变更记录信息的标记信息，有效的查找新抬头和旧抬头的当前状态信息以及状态转移关系，从而可以将发票抬头恢复到变更前的某个中间状态或原始状态，并提供实时的数据回滚，进而更加有效的实现整个变更过程中的错误排查。
此外，通过本申请实施例，可以更准确高效的进行发票抬头信息的变更，并且更加易于发票管理系统的维护和更新，也降低开发难度和维护成本。
实施例三
参照图4，示出了本申请的一种发票抬头信息变更流程状态转移的实施例示意图，其包括了变更前、变更过程、以及变更结束的整个变更流程。如图4所示，整个变更流程中包含：原始抬头有效；新抬头待审核、旧抬头锁定；新抬头拒绝、旧抬头锁定；新抬头撤销、旧抬头有效；新抬头有效、旧抬头失效；以及新抬头失效，共六种状态之间的转移。
1)在发票原始抬头处于有效的状态下，如果新抬头信息在变更流程中需要进行财务审核，则由原始抬头有效的状态转移到新抬头待审核、旧抬头锁定的状态；此时，生成的影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息。所述影子抬头数据表中当前变更记录信息包括与变更相关的信息，例如，变更前已经生效的旧抬头信息，新抬头和旧抬头的当前状态信息，用以指示新抬头和旧抬头的状态转移关系的标记信息等。在本申请实施例中，该当前变更记录信息包括用来指示由原始抬头有效的状态转移到新抬头待审核、旧抬头锁定的状态的标示信息；如果新抬头信息在变更流程中不需要财务审核，则原始抬头有效的状态直接更新为新抬头有效、旧抬头失效的状态，期间并不会伴随影子抬头数据表的生成。
2)在新抬头待审核、旧抬头锁定的状态下，如果新抬头信息未通过财务审核，则由新抬头待审核、旧抬头锁定的状态转移到新抬头拒绝、旧抬头锁定的状态；此时，生成的影子抬头数据表包括原始抬头信息、新抬头信息、变更前已经生效的旧抬头信息、当前变更记录信息、新抬头和旧抬头的当前状态信息。其中该当前变更记录信息包括用来指示由新抬头待审核、旧抬头锁定的状态转移到新抬头拒绝、旧抬头锁定的状态的标示信息；
如果新抬头信息财务审核成功，那么由新抬头待审核、旧抬头锁定的状态转移到新抬头有效、旧抬头失效的状态；此时，生成的影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息。其中该当前变更记录信息包括用来指示由新抬头待审核、旧抬头锁定的状态转移到新抬头有效、旧抬头失效的状态的标示信息；
而如果此时用户欲终止本次变更流程，则可以撤销本次变更的操作，那么由新抬头待审核、旧抬头锁定的状态转移到新抬头撤销、旧抬头有效的状态；此时，生成的影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息。其中该当前变更记录信息包括用来指示由新抬头待审核、旧抬头锁定的状态转移到新抬头撤销、旧抬头有效的状态的标示信息。
3)在新抬头拒绝、旧抬头锁定的状态下，如果新抬头信息修改好之后重新进行财务审核，那么由新抬头拒绝、旧抬头锁定的状态转移回到新抬头待审核、旧抬头锁定的状态；此时，生成的影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息。其中该当前变更记录信息包括用来指示由新抬头拒绝、旧抬头锁定的状态转移回到新抬头待审核、旧抬头锁定的状态的标示信息；
而如果此时用户欲终止本次变更流程，则可以撤销本次变更的操作，那么由新抬头 拒绝、旧抬头锁定的状态转移到新抬头撤销、旧抬头有效的状态；此时，生成的影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息。其中该当前变更记录信息包括用来指示由新抬头拒绝、旧抬头锁定的状态转移到新抬头撤销、旧抬头有效的状态的标示信息。
4)在新抬头撤销、旧抬头有效状态下，如果直接驳回，那么由新抬头撤销、旧抬头有效的状态转移到新抬头失效的状态。
5)在新抬头有效、旧抬头失效状态下，如果直接驳回，那么由新抬头有效、旧抬头失效的状态转移到新抬头失效的状态。
6)在新抬头失效的状态下，系统可以从失效的抬头中选择一个抬头进行编辑，生效之后再次进入变更流程。
需要说明的是，如果失效的场景是系统自动所为的，比如系统重大变更，有可能会导致用户之前所有发票的抬头信息全部失效。而当用户再次进入系统时，有可能需要之前的抬头信息。所以，在一个优选的实施例中，可以提供给用户从失效的抬头中选择一个失效抬头做继续操作的方式。具体应用时，可以将该用户所有的失效抬头都列出来，然后由用户从中选择一个进行后续操作。
本申请实施例具备以下优点：
本申请实施例可以在变更发票抬头信息过程中，基于变更请求生成对应的影子抬头数据表，可以通过查找该影子抬头数据表中所包括的原始抬头信息、新抬头信息、当前变更记录信息，更准确有效的进行发票抬头信息的变更，从而提高用户体验。
进一步的，当用户在对发票抬头信息进行若干次变更后，如因遇到某种情况而需要执行撤销操作时，通过该影子抬头数据表中当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；还可以通过该影子抬头数据表中当前变更记录信息的标记信息，有效的查找新抬头和旧抬头的当前状态信息以及状态转移关系，从而可以将发票抬头恢复到变更前的某个中间状态或原始状态，并提供实时的数据回滚，进而更加有效的实现整个变更过程中的错误排查。
实施例四
下面，结合一实际业务场景来说明本申请实施例的一种具体应用。
例如，企业从小规模纳税人变更为一般纳税人，则发票需要从企业增值税普通发票变更为企业增值税专用发票。一般的，此时需要变更的抬头项目包括：税务登记证号、 注册场所地址、公司注册电话、银行账户信息等。
用户进入发票管理界面，通过调取接口调取服务器上的数据库信息得到发票抬头信息列表。用户点击想要修改的发票抬头信息进入变更流程，如图5所示，为发票抬头信息变更方法实施例的业务流程示意图。
首先，用户选择变更类型，即由企业增值税普通发票变更为企业增值税专用发票；然后，由于是从企业增值税普通发票变更为企业增值税专用发票，所以判断开具类型无需变更；接下来，确定抬头名称需要发生变更后，进一步判断不是抬头名称填写错误，则用户提交登记变更信息；系统判断是企业增值税专用发票，则需要用户提交企业增值税专用发票的抬头及其他信息，提交工商变更证明，系统进行财务审核；
如果财务审核未通过，系统在生成的影子抬头数据表中当前变更记录信息里更新为新抬头拒绝、旧抬头锁定状态，此时，如果用户欲终止本次变更流程，则可以点击撤销按钮，系统将撤销本次变更操作，这样，则系统会在影子抬头数据表中当前变更记录信息里对新抬头和旧抬头的状态进行更新，并记录由新抬头拒绝、旧抬头锁定的状态转移到新抬头撤销、旧抬头有效的状态转移关系；同时，系统会根据影子抬头数据表中当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息。当然，对于财务审核未通过的情况，用户还可以按照系统提示修改后重新提交，重新进行财务审核；如果财务审核通过，则提交的新抬头有效；结束变更流程。
本申请实施例具备以下优点：
本申请实施例可以在变更发票抬头信息过程中，基于变更请求生成对应的影子抬头数据表，可以通过查找该影子抬头数据表中所包括的原始抬头信息、新抬头信息、当前变更记录信息，更准确有效的进行发票抬头信息的变更，从而提高用户体验。
进一步的，当用户在对发票抬头信息进行若干次变更后，如因遇到某种情况而需要执行撤销操作时，通过该影子抬头数据表中当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；还可以通过该影子抬头数据表中当前变更记录信息的标记信息，有效的查找新抬头和旧抬头的当前状态信息以及状态转移关系，从而可以将发票抬头恢复到变更前的某个中间状态或原始状态，并提供实时的数据回滚，进而更加有效的实现整个变更过程中的错误排查。
此外，通过本申请实施例，可以更准确高效的进行发票抬头信息的变更，并且更加易于发票管理系统的维护和更新，也降低开发难度和维护成本。
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组 合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。
实施例五
参照图6，示出了本申请的一种发票抬头信息变更装置实施例的结构框图，具体可以包括如下模块：
接收模块610，用于接收用户提交的发票抬头信息变更请求；
确定模块620，用于基于预置规则确定所述接收模块接收到的变更请求是否需要进行财务审核；其中，在本申请另一实施例中，所述确定模块620还可以用于确定原始抬头处于有效状态。
可以理解的是，在实际应用中，某些业务场景在变更流程中是不需要进行财务审核的，例如，个人或者企业增值税普通发票的抬头填写错误的变更等。而某些业务场景在变更流程中是需要进行财务审核的，例如，企业增值税普通发票变更为企业增值税专用发票，企业增值税专用发票的抬头名称变更，个人增值税普通发票变更为企业增值税专用发票等。因此，本申请实施例所述的预置规则，是根据具体的财务审核标准预先设置在系统内的，在确定变更请求是否需要进行财务审核时，就依照该预置规则进行判断即可。
生成模块630，用于若所述确定模块620确定需要进行财务审核，则基于变更请求生成对应的影子抬头数据表，其中，所述影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息；
需要说明的是，所述影子抬头数据表中当前变更记录信息包括与变更相关的信息，例如，变更前已经生效的旧抬头信息，新抬头和旧抬头的当前状态信息等。
变更模块640，用于若新抬头信息通过财务审核，则将发票旧抬头信息变更为新抬头信息。相应的，所述生成模块630，还用于更新所述影子抬头数据表中当前变更记录信息的新抬头状态为有效、旧抬头状态为失效。
本申请实施例可以在变更发票抬头信息过程中，基于变更请求生成对应的影子抬头数据表，可以通过查找该影子抬头数据表中所包括的原始抬头信息、新抬头信息、当前变更记录信息，更准确有效的进行发票抬头信息的变更，从而提高用户体验。此外，通 过本申请实施例，可以更准确高效的进行发票抬头信息的变更，并且更加易于发票管理系统的维护和更新，也降低开发难度和维护成本。
实施例六
参照图7，示出了本申请的另一种发票抬头信息变更装置实施例的结构框图，具体可以包括如下模块：
接收模块710，用于接收用户提交的发票抬头信息变更请求；
确定模块720，用于基于预置规则确定所述接收模块接收到的变更请求是否需要进行财务审核；其中，在本申请另一实施例中，所述确定模块720还可以用于确定原始抬头处于有效状态。可以理解的是，发票原始抬头需要处于有效状态才能进行后续的变更流程，故在进入变更流程之前需要确定原始抬头的状态为有效状态。至于具体采用什么方式判定发票的原始抬头状态，本发明实施例不做限制。
可以理解的是，在实际应用中，某些业务场景在变更流程中是不需要进行财务审核的，例如，个人或者企业增值税普通发票的抬头填写错误的变更等。而某些业务场景在变更流程中是需要进行财务审核的，例如，企业增值税普通发票变更为企业增值税专用发票，企业增值税专用发票的抬头名称变更，个人增值税普通发票变更为企业增值税专用发票等。因此，本申请实施例所述的预置规则，是根据具体的财务审核标准预先设置在系统内的，在确定变更请求是否需要进行财务审核时，就依照该预置规则进行判断即可。
生成模块730，用于若所述确定模块720确定需要进行审核，则基于变更请求生成对应的影子抬头数据表，其中，所述影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息；
需要说明的是，所述影子抬头数据表中当前变更记录信息包括与变更相关的信息，例如，变更前已经生效的旧抬头信息，新抬头和旧抬头的当前状态信息，用以指示新抬头和旧抬头的状态转移关系的标记信息等。
优选的，在本申请实施例中，可以参照图2所示，生成模块730可以根据变更请求1生成对应的影子抬头数据表1，该影子抬头数据表1至少包括：原始抬头信息、新抬头信息、当前变更记录信息。如果接下来还有变更请求2，则生成模块730还可以根据变更请求2生成对应的影子抬头数据表2，该影子抬头数据表2至少包括：原始抬头信息、新抬头信息、当前变更记录信息。可以理解的是，以此类推，如果接下来还有变更请求 n，则生成模块730还可以根据变更请求n生成对应的影子抬头数据表n。
变更模块740，用于若新抬头信息通过财务审核，则将发票旧抬头信息变更为新抬头信息；相应的，所述生成模块730，还用于更新所述影子抬头数据表中当前变更记录信息的新抬头状态为有效、旧抬头状态为失效。
可以理解的是，所述影子抬头数据表的当前变更记录信息包括标记信息，用以指示新抬头和旧抬头的状态转移关系。例如，生成模块730在所述影子抬头数据表中通过设置标示符或标记代码等来实现新抬头和旧抬头的状态转移关系的标记。可以理解的是，生成模块730在所述影子抬头数据表中记录当前变更记录信息的具体实现方式并不局限于本申请实施例的实现方式，还可以有多种，只要能够用来指示新抬头和旧抬头的状态转移关系即可，为此，本申请实施例对此不做限制。
查找模块750，用于在符合预置条件的情况下，基于所述接收模块710接收的用户提交的撤销变更请求，查找所述影子抬头数据表的当前变更记录信息；
所述变更模块740，还用于基于所述查找模块740查找到的所述当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；相应的，
所述生成模块730，还用于更新所述影子抬头数据表中当前变更记录信息的新抬头状态为撤销、旧抬头状态为有效。
在一个优选的实施例中，所述预置条件为：所述新抬头信息处于待审核状态；
则所述生成模块730，还用于当所述新抬头信息处于待审核状态时，更新所述影子抬头数据表的新抬头状态为待审核、旧抬头状态为锁定；
在另一个优选的实施例中，所述预置条件为：所述新抬头信息未通过财务审核；
则所述生成模块730，还用于当所述新抬头信息未通过审核时，更新所述影子抬头数据表的新抬头状态为拒绝、旧抬头状态为锁定。
另外，所述变更模块740，还用于若所述确定模块720确定不需要进行财务审核，则将发票旧抬头信息变更为新抬头信息。
优选的，本申请实施例还可以包括保存模块760，用于发票抬头信息变更流程结束后，将新抬头信息及变更过程中生成的影子抬头数据表保存在数据库中。
本申请实施例可以在变更发票抬头信息过程中，基于变更请求生成对应的影子抬头数据表，可以通过查找该影子抬头数据表中所包括的原始抬头信息、新抬头信息、当前变更记录信息，更准确有效的进行发票抬头信息的变更，从而提高用户体验。
进一步的，当用户在对发票抬头信息进行若干次变更后，如因遇到某种情况而需要 执行撤销操作时，通过该影子抬头数据表中当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；还可以通过该影子抬头数据表中当前变更记录信息的标记信息，有效的查找新抬头和旧抬头的当前状态信息以及状态转移关系，从而可以将发票抬头恢复到变更前的某个中间状态或原始状态，并提供实时的数据回滚，进而更加有效的实现整个变更过程中的错误排查。
此外，通过本申请实施例，可以更准确高效的进行发票抬头信息的变更，并且更加易于发票管理系统的维护和更新，也降低开发难度和维护成本。
实施例七
参照图8，示出了本申请的一种发票管理系统实施例的架构图，该发票管理系统800包括发票抬头信息变更装置810和数据库820，所述发票抬头信息变更装置810的具体结构说明请参见上述实施例，此处不再赘述。
用户可以在线通过客户端访问发票管理中心服务器上的发票管理系统800对发票抬头信息进行管理。具体而言，发票管理系统800的发票抬头信息变更装置810收到用户发票抬头信息的变更请求后，基于后台服务器根据发票的类型给予相应的处理，并将相关的数据信息保存到发票管理系统800的数据库820中。
需要说明的是，本申请实施例的发票管理系统可以应用到发票管理中心服务器或发票管理平台上，本申请实施例对此不做限制。
本申请实施例，具备以下优点：
本申请实施例可以在变更发票抬头信息过程中，基于变更请求生成对应的影子抬头数据表，可以通过查找该影子抬头数据表中所包括的原始抬头信息、新抬头信息、当前变更记录信息，更准确有效的进行发票抬头信息的变更，从而提高用户体验。
进一步的，当用户在对发票抬头信息进行若干次变更后，如因遇到某种情况而需要执行撤销操作时，通过该影子抬头数据表中当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；还可以通过该影子抬头数据表中当前变更记录信息的标记信息，有效的查找新抬头和旧抬头的当前状态信息以及状态转移关系，从而可以将发票抬头恢复到变更前的某个中间状态或原始状态，并提供实时的数据回滚，进而更加有效的实现整个变更过程中的错误排查。
此外，通过本申请实施例，可以更准确高效的进行发票抬头信息的变更，并且更加 易于发票管理系统的维护和更新，也降低开发难度和维护成本。
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD@ROM、光学存储器等)上实施的计算机程序产品的形式。
在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD@ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。
本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本申请所提供的一种发票抬头信息变更方法、装置及一种发票管理系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均可有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (19)

  1. 一种发票抬头信息变更方法，其特征在于，包括：
    接收用户提交的发票抬头信息变更请求；
    基于预置规则确定所述变更请求是否需要进行审核；
    如果需要进行审核，则基于变更请求生成对应的影子抬头数据表，其中，所述影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息；
    若新抬头信息通过审核，则将发票旧抬头信息变更为新抬头信息；以及，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为有效、旧抬头状态为失效。
  2. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    在符合预置条件的情况下，基于用户提交的撤销变更请求和所述影子抬头数据表的当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；以及，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为撤销、旧抬头状态为有效。
  3. 根据权利要求2所述的方法，其特征在于，
    所述预置条件为：所述新抬头信息未通过审核；
    则所述方法还包括：当所述新抬头信息未通过审核时，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为拒绝、旧抬头状态为锁定；
    或者
    所述预置条件为：所述新抬头信息处于待审核状态；
    则所述方法还包括：当所述新抬头信息处于待审核状态时，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为待审核、旧抬头状态为锁定。
  4. 根据权利要求1-3任一项所述的方法，其特征在于，所述影子抬头数据表中当前变更记录信息还包括：用以指示新抬头和旧抬头的状态转移关系的标记信息。
  5. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    如果不需要进行审核，则将发票旧抬头信息变更为新抬头信息。
  6. 一种发票抬头信息变更方法，其特征在于，包括：
    接收用户提交的发票抬头信息变更请求；
    基于预置规则确定所述变更请求是否需要进行审核；
    如果需要进行审核，则基于变更请求生成对应的影子抬头数据表，其中，所述影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息；
    在符合预置条件的情况下，基于用户提交的撤销变更请求和所述影子抬头数据表的 当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；以及，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为撤销、旧抬头状态为有效。
  7. 根据权利要求6所述的方法，其特征在于，
    所述预置条件为：所述新抬头信息未通过审核；
    则所述方法还包括：当所述新抬头信息未通过审核时，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为拒绝、旧抬头状态为锁定；
    或者
    所述预置条件为：所述新抬头信息处于待审核状态；
    则所述方法还包括：当所述新抬头信息处于待审核状态时，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为待审核、旧抬头状态为锁定。
  8. 根据权利要求6或7所述的方法，其特征在于，所述影子抬头数据表中当前变更记录信息还包括：用以指示新抬头和旧抬头的状态转移关系的标记信息。
  9. 根据权利要求6所述的方法，其特征在于，所述方法还包括：
    如果不需要进行审核，则将发票旧抬头信息变更为新抬头信息。
  10. 一种发票抬头信息变更装置，其特征在于，包括：
    接收模块，用于接收用户提交的发票抬头信息变更请求；
    确定模块，用于基于预置规则确定所述接收模块接收到的变更请求是否需要进行审核；
    生成模块，用于若所述确定模块确定需要进行审核，则基于变更请求生成对应的影子抬头数据表，其中，所述影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息；
    变更模块，用于若新抬头信息通过审核，则将发票旧抬头信息变更为新抬头信息；相应的，所述生成模块，还用于更新所述影子抬头数据表中当前变更记录信息的新抬头状态为有效、旧抬头状态为失效。
  11. 根据权利要求10所述的装置，其特征在于，所述装置还包括：
    查找模块，用于在符合预置条件的情况下，基于所述接收模块接收的用户提交的撤销变更请求，查找所述影子抬头数据表的当前变更记录信息；
    所述变更模块，还用于基于所述查找模块查找到的所述当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；相应的，
    所述生成模块，还用于更新所述影子抬头数据表中当前变更记录信息的新抬头状态 为撤销、旧抬头状态为有效。
  12. 根据权利要求11所述的装置，其特征在于，
    所述预置条件为：所述新抬头信息未通过审核；
    则所述生成模块，还用于当所述新抬头信息未通过审核时，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为拒绝、旧抬头状态为锁定；
    或者
    所述预置条件为：所述新抬头信息处于待审核状态；
    则所述生成模块，还用于当所述新抬头信息处于待审核状态时，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为待审核、旧抬头状态为锁定。
  13. 根据权利要求10-12任一项所述的装置，其特征在于，所述影子抬头数据表中当前变更记录信息还包括：用以指示新抬头和旧抬头的状态转移关系的标记信息。
  14. 根据权利要求10所述的装置，其特征在于，所述变更模块，还用于若所述确定模块确定不需要进行审核，则将发票旧抬头信息变更为新抬头信息。
  15. 一种发票抬头信息变更装置，其特征在于，包括：
    接收模块，用于接收用户提交的发票抬头信息变更请求；
    确定模块，用于基于预置规则确定所述接收模块接收到的变更请求是否需要进行审核；
    生成模块，用于若所述确定模块确定需要进行审核，则基于变更请求生成对应的影子抬头数据表，其中，所述影子抬头数据表包括原始抬头信息、新抬头信息、当前变更记录信息；
    查找模块，用于在符合预置条件的情况下，基于所述接收模块接收的用户提交的撤销变更请求，查找所述影子抬头数据表的当前变更记录信息；
    变更模块，用于基于所述查找模块查找到的所述当前变更记录信息，将发票新抬头信息恢复成变更前已经生效的旧抬头信息；相应的，所述生成模块，还用于更新所述影子抬头数据表中当前变更记录信息的新抬头状态为撤销、旧抬头状态为有效。
  16. 根据权利要求15所述的装置，其特征在于，
    所述预置条件为：所述新抬头信息未通过审核；
    则所述生成模块，还用于当所述新抬头信息未通过审核时，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为拒绝、旧抬头状态为锁定；或者
    所述预置条件为：所述新抬头信息处于待审核状态；
    则所述生成模块，还用于当所述新抬头信息处于待审核状态时，更新所述影子抬头数据表中当前变更记录信息的新抬头状态为待审核、旧抬头状态为锁定。
  17. 根据权利要求15或16所述的装置，其特征在于，所述影子抬头数据表中当前变更记录信息还包括：用以指示新抬头和旧抬头的状态转移关系的标记信息。
  18. 根据权利要求15所述的装置，其特征在于，所述变更模块，还用于若所述确定模块确定不需要进行审核，则将发票旧抬头信息变更为新抬头信息。
  19. 一种发票管理系统，其特征在于，包括如权利要求10或15所述的发票抬头信息变更装置。
PCT/CN2017/072406 2016-02-05 2017-01-24 一种发票抬头信息变更方法、装置和发票管理系统 Ceased WO2017133570A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610080755.6 2016-02-05
CN201610080755.6A CN107045695A (zh) 2016-02-05 2016-02-05 一种发票抬头信息变更方法、装置和发票管理系统

Publications (1)

Publication Number Publication Date
WO2017133570A1 true WO2017133570A1 (zh) 2017-08-10

Family

ID=59499373

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/072406 Ceased WO2017133570A1 (zh) 2016-02-05 2017-01-24 一种发票抬头信息变更方法、装置和发票管理系统

Country Status (3)

Country Link
CN (1) CN107045695A (zh)
TW (1) TW201802739A (zh)
WO (1) WO2017133570A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110084655A (zh) * 2019-05-05 2019-08-02 腾讯科技（深圳）有限公司 电子票据处理方法、装置、计算机设备及计算机存储介质
CN112270529A (zh) * 2020-10-29 2021-01-26 北京字跳网络技术有限公司 业务表单的审批方法、装置、电子设备和存储介质
CN112633958A (zh) * 2020-12-22 2021-04-09 畅捷通信息技术股份有限公司 自动展示不同操作模块的方法

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110738533A (zh) * 2018-07-20 2020-01-31 北京京东尚科信息技术有限公司 一种发票管理系统和方法
CN109919572A (zh) * 2019-01-24 2019-06-21 贝壳技术有限公司 一种房产交易流程的变更方法及装置
CN113592570B (zh) * 2021-06-09 2024-05-28 青岛海尔科技有限公司 确定发票地址的方法及装置、维护方法及装置和发票系统
CN117408764B (zh) * 2023-12-13 2024-05-03 江西曼荼罗软件有限公司 一种医疗费别变更方法、系统、存储介质及电子设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1687951A (zh) * 2005-05-30 2005-10-26 中国民生银行股份有限公司 一种基于票据的数据处理系统和处理方法
CN101236519A (zh) * 2008-03-05 2008-08-06 中国原子能科学研究院 一种放射源管制应用级别备份恢复方法
US20150242966A1 (en) * 2007-08-13 2015-08-27 Phillip Marlowe Method, System, and Computer Readable Medium for Electronic Auditing

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102867375A (zh) * 2012-09-18 2013-01-09 北京国电通网络技术有限公司 一种发票管理系统和方法
CN102903171B (zh) * 2012-09-21 2014-05-07 国网山东省电力公司物资公司 自助式智能录入验审发票处理系统与方法
US20150127531A1 (en) * 2013-11-06 2015-05-07 Pax8, Inc. Real time recurring distributor billing for subscription products
CN104484820A (zh) * 2015-01-07 2015-04-01 税友软件集团股份有限公司 一种电子发票获取方法及系统
CN104881737A (zh) * 2015-05-19 2015-09-02 国网辽宁省电力有限公司盘锦供电公司 调控图形开票系统
CN105005929A (zh) * 2015-07-14 2015-10-28 浪潮软件集团有限公司 一种发票代开的预审采集方法及系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1687951A (zh) * 2005-05-30 2005-10-26 中国民生银行股份有限公司 一种基于票据的数据处理系统和处理方法
US20150242966A1 (en) * 2007-08-13 2015-08-27 Phillip Marlowe Method, System, and Computer Readable Medium for Electronic Auditing
CN101236519A (zh) * 2008-03-05 2008-08-06 中国原子能科学研究院 一种放射源管制应用级别备份恢复方法

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110084655A (zh) * 2019-05-05 2019-08-02 腾讯科技（深圳）有限公司 电子票据处理方法、装置、计算机设备及计算机存储介质
CN110084655B (zh) * 2019-05-05 2023-06-23 腾讯科技（深圳）有限公司 电子票据处理方法、装置、计算机设备及计算机存储介质
CN112270529A (zh) * 2020-10-29 2021-01-26 北京字跳网络技术有限公司 业务表单的审批方法、装置、电子设备和存储介质
CN112270529B (zh) * 2020-10-29 2024-05-17 北京字跳网络技术有限公司 业务表单的审批方法、装置、电子设备和存储介质
CN112633958A (zh) * 2020-12-22 2021-04-09 畅捷通信息技术股份有限公司 自动展示不同操作模块的方法

Also Published As

Publication number Publication date
CN107045695A (zh) 2017-08-15
TW201802739A (zh) 2018-01-16

Similar Documents

Publication Publication Date Title
WO2017133570A1 (zh) 一种发票抬头信息变更方法、装置和发票管理系统
US11762823B2 (en) Method and system for cloning enterprise content management systems
US11582043B2 (en) Systems, apparatus and methods for backing up and auditing distributed ledger data within a network and securely without using private keys
CN110032598B (zh) 字段更新方法及装置、电子设备
TW202008196A (zh) 基於中心化結算與區塊鏈存證的交易方法及系統
US20210149883A1 (en) Data structure reading methods and apparatuses, data structure update methods and apparatuses, and electronic devices
US8874455B2 (en) Convergence of customer and internal assets
US20160210597A1 (en) System for efficient processing of transaction requests related to an account in a database
WO2020029629A1 (zh) 一种基于中心化结算与区块链存证的交易方法及系统
US11775507B2 (en) Methods and apparatuses for reading and updating data structures, and electronic devices
US11488162B2 (en) Automatically storing metrics relating to payments in a blockchain
CN109933593B (zh) 资产数据记载方法、装置及设备
US10951540B1 (en) Capture and execution of provider network tasks
CN106980638B (zh) 操作记录系统、方法和操作对象变更信息查询方法
CN107016016A (zh) 一种数据处理的方法及装置
CN114996281A (zh) 数据处理系统、方法、装置、电子设备及存储介质
CN106855821B (zh) 一种分布式事务处理方法及装置
WO2020088072A1 (zh) 一种容灾数据处理方法、装置及系统
CN115168894A (zh) 数据安全的管控方法及装置、电子设备、存储介质
CN105989064A (zh) 一种记录信息的核对方法及装置
US20140351818A1 (en) Method and system for input driven process flow management
CN114444478A (zh) 一种凭证可视化方法、装置、电子设备及存储介质
CN112035156A (zh) 一种电商平台对接装置、方法、设备及介质
CN116362733A (zh) 资源转移方法、装置、计算机设备、存储介质
US12164975B2 (en) Federated distributed mutation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17746890

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17746890

Country of ref document: EP

Kind code of ref document: A1