CN115271835A - Invoice generation method and device, electronic equipment and storage medium - Google Patents

Invoice generation method and device, electronic equipment and storage medium Download PDF

Info

Publication number
CN115271835A
CN115271835A CN202110477056.6A CN202110477056A CN115271835A CN 115271835 A CN115271835 A CN 115271835A CN 202110477056 A CN202110477056 A CN 202110477056A CN 115271835 A CN115271835 A CN 115271835A
Authority
CN
China
Prior art keywords
billing
serial number
target
information
service
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.)
Pending
Application number
CN202110477056.6A
Other languages
Chinese (zh)
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.)
SF Technology Co Ltd
Original Assignee
SF Technology Co 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 SF Technology Co Ltd filed Critical SF Technology Co Ltd
Priority to CN202110477056.6A priority Critical patent/CN115271835A/en
Publication of CN115271835A publication Critical patent/CN115271835A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/04Billing or invoicing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Accounting & Taxation (AREA)
  • Data Mining & Analysis (AREA)
  • Computational Linguistics (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The application provides an invoice generation method, an invoice generation device, electronic equipment and a storage medium, wherein the invoice generation method comprises the following steps: acquiring a target billing request initiated by a service end; acquiring a target service serial number corresponding to the target billing request based on the target billing request; judging whether a target service serial number exists in a first database, wherein the first database is used for storing the service serial number corresponding to the received invoicing request; and if the target service serial number does not exist in the first database, invoicing is carried out on the service end based on the target invoicing request. The method and the device have the advantages that the first database is used for storing the business serial number corresponding to the received billing request, when a new target billing request is received, whether the business serial number corresponding to the target billing request is stored in the first database is judged firstly, if the business serial number does not exist, other requests for billing the target business serial number do not exist at the moment, billing of only one billing request can be guaranteed, and repeated billing is avoided.

Description

Invoice generation method and device, electronic equipment and storage medium
Technical Field
The application relates to the technical field of invoicing, in particular to an invoice generation method, an invoice generation device, electronic equipment and a storage medium.
Background
With the development of economic society, more and more enterprises and individuals have the requirement of invoicing, and the tax bureau hall faces larger invoicing workload. At present, when a basic tax office tax service hall issues invoices, taxpayer invoicing information needs to be input into a related tax system, and working links such as prepayment of tax, invoice printing and the like need to be completed. The handling of other services is delayed, meanwhile, the work has high repeatability, but a large amount of manpower and material resources are occupied, talents are wasted, and the invoice invalidation rate caused by errors is high. Tax authorities all have hoped to realize self-service generation, release artificial resources, and enable taxpayers to generate more flexibly and conveniently. Each company has also proposed several solutions in succession, but the effect is not ideal in the actual application process. For example, duplicate invoicing may occur due to an excessive number of invoicing requests.
That is, the invoice generation method in the prior art is easy to cause repeated invoicing.
Disclosure of Invention
The application aims to provide an invoice generation method, an invoice generation device, electronic equipment and a storage medium, and aims to solve the problem that repeated invoicing is easily caused by an invoice generation method in the prior art.
In one aspect, the present application provides an invoice generating method, including:
acquiring a target billing request initiated by a service end;
acquiring a target service serial number corresponding to the target billing request based on the target billing request;
judging whether the target service serial number exists in a first database, wherein the first database is used for storing the service serial number corresponding to the received billing request;
and if the target service serial number does not exist in the first database, invoicing is carried out on the service end based on the target invoicing request.
Optionally, the determining whether the target service serial number exists in the first database includes:
acquiring information to be verified corresponding to the target service serial number;
verifying whether the information to be verified is correct or not;
and if the information to be verified is correct, judging whether the target service serial number exists in the first database.
Optionally, the obtaining of the to-be-verified information corresponding to the target service serial number includes:
writing the target business serial number into a preset message middleware by using the billing microservice as a producer;
monitoring the preset message middleware by using basic data microservice as a consumer;
and acquiring information to be verified corresponding to the target service serial number when the target service serial number in the preset message middleware is monitored through the basic data micro-service.
Optionally, the invoicing the service terminal based on the target invoicing request includes:
obtaining billing data corresponding to the target service serial number;
sending the billing data to a third party billing platform for billing;
acquiring billing information returned by the third party billing platform;
and sending the billing information to the service end.
Optionally, the sending the billing information to the service end, before, includes:
writing the target service serial number into the first database;
after the target service serial number is written into the first database, setting a timing task for the first database, wherein the timing task is as follows: and deleting the target service serial number when the time written into the target service serial number reaches preset time by the first database.
Optionally, the sending the billing data to a third party billing platform for billing includes:
calculating bill information corresponding to the billing data based on the billing data;
sending the bill information to a service end for bill information confirmation;
and when the confirmation information returned by the service end is acquired, the billing data is sent to a third party billing platform for billing.
Optionally, the issuing information includes an issuing state, and the sending the issuing information to the service end includes:
judging whether the billing state is successful;
and if the billing state is successful, sending the billing information to the service end, and calling uplink micro-service to write the billing information into a preset alliance chain.
In one aspect, the present application provides an invoice generating apparatus, including:
the first obtaining unit is used for obtaining a target billing request initiated by a service end;
a second obtaining unit, configured to obtain, based on the target billing request, a target service serial number corresponding to the target billing request;
the judging unit is used for judging whether the target service serial number exists in a first database, wherein the first database is used for storing the service serial number corresponding to the received invoicing request;
and the billing unit is used for billing the service end based on the target billing request if the target service serial number does not exist in the first database.
Optionally, the invoice generating device further comprises a basic data unit,
the billing unit is used for acquiring information to be verified corresponding to the target service serial number;
the basic data unit is used for verifying whether the information to be verified is correct or not;
and the judging unit is used for judging whether the target service serial number exists in the first database or not if the information to be verified is correct.
Optionally, the billing unit is configured to:
writing the target business serial number into a preset message middleware by using the billing microservice as a producer;
utilizing basic data microservices as consumers to monitor the preset message middleware;
and acquiring information to be verified corresponding to the target service serial number when the target service serial number in the preset message middleware is monitored through the basic data micro-service.
Optionally, the billing unit is configured to:
acquiring billing data corresponding to the target service serial number;
sending the billing data to a third party billing platform for billing;
acquiring billing information returned by the third party billing platform;
and sending the billing information to the service end.
Optionally, the billing unit is configured to:
writing the target service serial number into the first database;
after the target service serial number is written into the first database, setting a timing task for the first database, wherein the timing task is as follows: and deleting the target service serial number when the time written into the target service serial number reaches preset time by the first database.
Optionally, the billing unit is configured to:
calculating bill information corresponding to the billing data based on the billing data;
sending the bill information to a service end for bill information confirmation;
and when the confirmation information returned by the service end is acquired, the billing data is sent to a third party billing platform for billing.
Optionally, the billing information includes a billing status, and the billing unit is configured to:
judging whether the billing state is successful;
and if the billing state is successful, sending the billing information to the service end, and calling uplink micro-service to write the billing information into a preset alliance chain.
In one aspect, the present application further provides an electronic device, including:
one or more processors;
a memory; and
one or more application programs, wherein the one or more application programs are stored in the memory and configured to be executed by the processor to implement the invoice generation method of any one of the first aspects.
In one aspect, the present application further provides a computer-readable storage medium on which a computer program is stored, the computer program being loaded by a processor to perform the steps in the invoice generation method of any one of the first aspects.
The application provides an invoice generation method, which comprises the following steps: acquiring a target billing request initiated by a service end; acquiring a target service serial number corresponding to the target billing request based on the target billing request; judging whether a target service serial number exists in a first database, wherein the first database is used for storing the service serial number corresponding to the received invoicing request; and if the target service serial number does not exist in the first database, invoicing is carried out on the service end based on the target invoicing request. The method and the device have the advantages that the first database is used for storing the service serial number corresponding to the received billing request, when a new target billing request is received, whether the first database stores the service serial number corresponding to the target billing request is judged firstly, if the service serial number does not exist, other requests for billing the target service serial number do not exist, billing of only one billing request can be guaranteed, and repeated billing is avoided.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the description below are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
FIG. 1 is a schematic view of a scenario of an invoice generation system provided by an embodiment of the present application;
FIG. 2 is a schematic flow chart diagram illustrating an embodiment of an invoice generation method provided by an embodiment of the present application;
FIG. 3 is a flowchart illustrating another embodiment of an invoice generation method provided by an embodiment of the present application;
FIG. 4 is a schematic structural diagram of an embodiment of an invoice generation apparatus provided in an embodiment of the present application;
fig. 5 is a schematic structural diagram of an embodiment of an electronic device provided in an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
In the description of the present application, it is to be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", and the like indicate orientations or positional relationships based on those shown in the drawings, and are used merely for convenience of description and for simplicity of description, and do not indicate or imply that the referenced device or element must have a particular orientation, be constructed in a particular orientation, and be operated, and thus should not be considered as limiting the present application. Furthermore, the terms "first", "second" and "first" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more features. In the description of the present application, "a plurality" means two or more unless specifically limited otherwise.
In this application, the word "exemplary" is used to mean "serving as an example, instance, or illustration. Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. The following description is presented to enable any person skilled in the art to make and use the application. In the following description, details are set forth for the purpose of explanation. It will be apparent to one of ordinary skill in the art that the present application may be practiced without these specific details. In other instances, well-known structures and processes are not set forth in detail in order to avoid obscuring the description of the present application with unnecessary detail. Thus, the present application is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
It should be noted that, since the method in the embodiment of the present application is executed in an electronic device, processing objects of each electronic device exist in the form of data or information, for example, time, which is substantially time information, and it can be understood that, if size, number, position, and the like are mentioned in subsequent embodiments, corresponding data exist so that the electronic device performs processing, which is not described herein again specifically.
The embodiments of the present application provide an invoice generating method, an invoice generating apparatus, an electronic device, and a storage medium, which are described in detail below.
Referring to fig. 1, fig. 1 is a schematic view of a scenario of an invoice generating system according to an embodiment of the present application, where the invoice generating system 110 may include an electronic device 111, and an invoice generating apparatus is integrated in the electronic device 111.
Specifically, the invoice generating system 110 is connected to the service end 120, the third party verification platform 130, the third party billing platform 140, and the default federation chain 150, respectively. The service end 120 may be a self-service billing machine, or a computer, a mobile phone, or other devices held by the user. The user may operate on an app operation interface or a browser of the service end 120, and initiate a target billing request. The third party verification platform 130 is used for verifying the information to be verified sent by the invoice generation system 110 in the process of making an invoice. The third party billing platform 140 is used for invoicing, for example, the third party billing platform 140 may be a tax bureau or other platform with invoicing qualifications. The default federation chain 150 is used to bill for data sent by the invoice generation system 110.
In this embodiment, the electronic device 111 may be an independent server, or may be a server network or a server cluster composed of servers, for example, the electronic device 111 described in this embodiment includes, but is not limited to, a computer, a network host, a single network server, multiple network server sets, or a cloud server composed of multiple servers. Among them, the Cloud server is constituted by a large number of computers or web servers based on Cloud Computing (Cloud Computing).
Those skilled in the art can understand that the application environment shown in fig. 1 is only one application scenario of the present application, and does not constitute a limitation on the application scenario of the present application, and that other application environments may further include more or fewer electronic devices than those shown in fig. 1, for example, only 1 electronic device is shown in fig. 1, and it is understood that the invoice generation system 110 may further include one or more other servers, which is not limited herein.
In addition, as shown in FIG. 1, the invoice generation system 110 may also include a memory 112 for storing data.
It should be noted that the scenario diagram of the invoice generating system 110 shown in fig. 1 is merely an example, the invoice generating system 110 and the scenario described in the embodiment of the present application are for more clearly illustrating the technical solution of the embodiment of the present application, and do not form a limitation on the technical solution provided in the embodiment of the present application, and as the invoice generating system 110 evolves and a new business scenario appears, the technical solution provided in the embodiment of the present application is also applicable to similar technical problems.
First, an invoice generating method is provided in an embodiment of the present application, where an execution subject of the invoice generating method is an invoice generating device, and the invoice generating device is applied to an electronic device, and the invoice generating method includes:
acquiring a target billing request initiated by a service end;
acquiring a target service serial number corresponding to the target billing request based on the target billing request;
judging whether a target service serial number exists in a first database, wherein the first database is used for storing the service serial number corresponding to the received invoicing request;
and if the target service serial number does not exist in the first database, invoicing is carried out on the service end based on the target invoicing request.
Referring to fig. 2, fig. 2 is a schematic flowchart of an embodiment of an invoice generation method provided in the embodiment of the present application. As shown in fig. 2, the invoice generation method includes:
201. and acquiring a target billing request initiated by a service end.
In the embodiment of the application, the service end can be a self-service billing machine, and can also be a computer, a mobile phone and other equipment held by a user. The user may operate on an app operation interface or a browser of the service end, and initiate a target billing request, and the invoice generating system 110 may obtain the target billing request initiated by the service end. For example, a user inputs a serial number of a service to be invoiced at a service end, and clicks a 'request for invoicing' button to initiate an invoicing request.
Specifically, multiple target billing requests may be obtained simultaneously, where the multiple target billing requests may be initiated by multiple service terminals respectively, or multiple target billing requests sent by the same service terminal. The target billing request may be obtained according to a preset period, and the preset period may be set according to an actual demand, for example, the preset period may be 1s, 2s, or another period. The preset periods for different time periods in a day may be set to different periods. For example, the preset period is set to a first period during the evening period of a day, and the preset period is set to a second period during the daytime period of the day, with the first period being greater than the second period. The acquisition cycle is increased at night, which may avoid increased system load caused by frequent acquisition requests by the invoice generation system 110 during low traffic.
202. And acquiring a target service serial number corresponding to the target billing request based on the target billing request.
Wherein, serial number generally refers to the number of a certain activity participant; the code of the bank; also applied to industrial production, each product has its unique serial number. For example, the service serial number is a service serial number corresponding to a single transportation service performed by a driver a driving a vehicle B on a transportation platform.
In the embodiment of the application, after the target billing request initiated by the service end is obtained, the target billing request is analyzed, and the target service serial number corresponding to the target billing request is obtained. Specifically, the service end sends a request to the invoice generating system 110 in the form of an agreed message for the service serial number of the user, and the invoice generating system 110 parses the message to obtain the target service serial number corresponding to the target billing request.
203. And judging whether a target service serial number exists in a first database, wherein the first database is used for storing the service serial number corresponding to the received invoicing request.
The first database is used for storing the service serial number corresponding to the received billing request, and the service serial number corresponding to the received billing request is the serial number entering the first database before the service end target billing request is acquired.
In the embodiment of the application, the target service serial number is matched with the service serial number corresponding to the received billing request stored in the first database, and whether the target service serial number exists in the first database is judged. If the target service serial number does not exist in the first database, invoicing is carried out on a service end based on the target invoicing request; and if the target service serial number exists in the first database, sending an instruction for suspending invoicing initiated on the target service serial number to the service end.
204. And if the target service serial number does not exist in the first database, invoicing is carried out on the service end based on the target invoicing request.
The method and the device have the advantages that the first database is used for storing the service serial number corresponding to the received billing request, when a new target billing request is received, whether the first database stores the service serial number corresponding to the target billing request is judged firstly, if the service serial number does not exist, other requests for billing the target service serial number do not exist, billing of only one billing request can be guaranteed, and repeated billing is avoided.
In a specific embodiment, invoicing the service end based on the target invoicing request may include:
(1) And acquiring billing data corresponding to the serial number of the target service.
In the embodiment of the application, the billing data corresponding to the target service serial number is read from the second database according to the target service serial number. Of course, the invoicing data filling page can also be sent to the service end, the user fills the invoicing data, and the invoicing data returned by the service end is obtained.
(2) And sending the billing data to a third party billing platform for billing.
Specifically, the invoice micro-service is utilized to send an invoice printing request to a third-party invoicing platform based on invoicing data, and the invoicing information returned by the third-party invoicing platform is waited. The invoice information can comprise invoice information and an invoice state, and the invoice information can be a printed electronic invoice. And the billing data corresponding to the plurality of target business serial numbers can be simultaneously sent to a third-party billing platform for billing.
(3) And acquiring billing information returned by the third-party billing platform.
The billing information comprises billing state and invoice information. The billing state comprises successful billing and failure billing. The invoice information may include "date of invoice", "invoice type", "invoice status", "failure reason", "invoice code", "invoice number", and the like.
(4) And sending the billing information to a service end.
And sending the billing information to a service end for downloading by a user.
In a specific embodiment, whether the billing state is successful is judged; and if the billing state is successful, the billing information is sent to the service end. And if the billing state is billing failure, acquiring failure reasons in the invoice information and sending the failure reasons to the service end. The billing state can be updated in time, so that the user can know the billing state in time.
Furthermore, after obtaining the billing information returned by the third-party billing platform, calling the uplink micro service to write the billing information into the preset alliance chain. And the alliance chain only aims at members of a certain specific group and limited third parties, a plurality of preselected nodes are internally designated as bookers, the generation of each block is jointly determined by all the preselected nodes, other access nodes can participate in transactions, but the billing process is not required to be asked, and other third parties can carry out limited inquiry through an API opened by the block chain. To achieve better performance, the federation chain places certain requirements on the configuration and network environment of the consensus or authentication node. With the admission mechanism, the transaction performance can be improved more easily, and problems caused by the participants with uneven participation can be avoided. For example, the tenuous union initiates as a chain builder, and constructs a alliance chain which takes a tax bureau, a supply chain platform, a supply enterprise and a transportation enterprise as main nodes and carries out data docking through a Tencent TBaaS platform. The invoicing information is written into a preset alliance chain, and the tax bureau can monitor the invoicing condition in real time, so that the out-of-control invoice is avoided.
Furthermore, after the billing information returned by the third-party billing platform is acquired, the billing state corresponding to the target business serial number is updated to be 'billed'. And after obtaining the billing information, storing and calling the uplink micro service to uplink the billing information, and transferring the invoice state flow to the invoiced invoice. Thereby forming an invoice issuing service closed loop and preventing the issuing invoice from being out of control from the supervision perspective.
When an inquiry instruction input by a user is obtained, acquiring an invoice code or an invoice number in the inquiry instruction, and calling an uplink micro-service to acquire service data corresponding to the invoice code or the invoice number from a preset alliance chain according to the invoice code or the invoice number. For example, according to a specific invoice issued by the tax control machine, an invoice code and an invoice number are provided, and a user finds out service data for issuing the invoice through "invoice source tracing" of the invoice generation system 110, including: cargo information, driver information and vehicle information to realize that each invoice can both fix a position business information, prevent that the invoice from making a false invoice, promote the authenticity of making an invoice.
Referring to fig. 3, fig. 3 is a schematic flowchart of another embodiment of an invoice generation method provided in the embodiment of the present application. As shown in fig. 3, the invoice generation method includes:
301. and acquiring a target billing request initiated by a service end.
In the embodiment of the present application, the specific steps of 301 may refer to 201 in the previous embodiment, which is not described herein again.
302. And acquiring a target service serial number corresponding to the target billing request based on the target billing request.
In the embodiment of the present application, the specific steps of 302 may refer to 202 in the previous embodiment, and are not described herein again.
303. And acquiring information to be verified corresponding to the target service serial number.
The information to be verified can include driver identity card information, driver driving license information, vehicle driving license information, road transportation operation license information, road transportation license information, driver contract and temporary tax registration information, and the content of the information to be verified can be set in advance. The information to be verified may be stored in the second database in advance, for example, the second database is a mysql database. And obtaining the information to be verified corresponding to the target service flow number by inquiring the mysql database. mysql is a relational database management system that keeps data in different tables instead of putting all the data in one large repository, which increases speed and flexibility. Of course, the second database may also be a conventional disk database such as Oracle, mongodb, postgresql, or the like, and may store data more persistently than the in-memory database. And the ACID mechanism of the traditional disk database is mature and reliable, and the safety of data storage can be improved.
In a specific embodiment, the obtaining of the to-be-verified information corresponding to the target service serial number may include: writing the target business serial number into a preset message middleware by using the billing microservice as a producer; utilizing basic data micro service as a middleware for monitoring preset messages by a consumer; and when the target service serial number in the preset message middleware is monitored through the basic data micro-service, acquiring to-be-verified information corresponding to the target service serial number. Specifically, the information to be verified corresponding to the target service serial number is obtained through the basic data micro-service.
Microservice is a cloud-native architecture approach in which a single application is composed of many loosely-coupled and independently deployable smaller components or services. These services typically have their own stack, including databases and data models; through the REST API, a combination of event streams and message brokers communicate with each other; they are organized by business capabilities, and the lines separating services are often referred to as bounded contexts. The code can be updated more easily. Teams may use different stacks for different components. The components may be scaled independently of each other, thereby reducing the waste and cost of having to scale an entire application, as a single function may face excessive load.
Wherein the preset message middleware is kafka. Message middleware, which is a bridge connecting message producers and message consumers. Kafka is a high-throughput distributed publish-subscribe messaging system that can handle all the action flow data in a consumer-scale website. In short, kafka is compared to a mailbox, where the producer is the person who sends the mail and the consumer is the person who receives the mail. The advantages of Kafka are as follows: high throughput, low latency: kafka can process hundreds of thousands of messages per second with a minimum delay of only a few milliseconds; and (3) expandability: the kafka cluster supports hot-scaling; durability and reliability: messages are persisted to local disk and support data backup to prevent data loss; fault tolerance: allowing nodes in the cluster to fail (if the number of copies is n, allowing n-1 nodes to fail); high concurrency: thousands of clients are supported to read and write simultaneously.
Specifically, a topic is declared in kafka that is used as a medium for the communication between the message producer and the message consumer. First a topic is created in kafka named ESG-RIP-CORE-CHAINBLOCK _ REQ. The billing micro-service is used as a message producer, and after receiving the target billing request, writes the target service serial number of the target billing request into the ESG-RIP-CORE-CHAINBLOCK _ REQ theme. The basic data microservice, as a message consumer, keeps listening to the content received in the subject ESG-RIP-CORE-CHAINBLOCK _ REQ. After the ESG-RIP-CORE-CHAINBLOCK _ REQ theme is monitored, the basic data micro-service analyzes a target service serial number of a target invoicing request, acquires information to be verified corresponding to the target service serial number, and calls a third party verification platform to verify whether the information to be verified is correct or not.
The number of the basic data microservices can be multiple, each basic microservice monitors one service serial number, and each basic microservice can monitor a plurality of service serial numbers simultaneously through multiple threads. Because a plurality of target billing requests can be simultaneously initiated, the plurality of target billing requests are sent to the message middleware for message queuing, and high throughput, low delay and high concurrency can be realized at the peak of the billing requests.
304. And verifying whether the information to be verified is correct.
Specifically, the third-party verification platform is called by using the basic data microservice to verify whether the information to be verified is correct, and if the information to be verified is correct, the step 305 is executed. If the information to be verified is incorrect, the request for refuting an invoice 312 is executed. Specifically, prompt information that the verification is unqualified is sent to the service end, and a user is prompted to restart the invoicing request after the information to be verified is updated.
305. And judging whether the target service serial number exists in the first database.
Specifically, if the target service serial number does not exist in the first database, 306 is executed; if the target service serial number exists in the first database, the request for refuting the invoice 312 is executed.
Furthermore, if the information to be verified is correct, the uplink micro service is called to write the billing information into the preset alliance chain.
306. And acquiring billing data corresponding to the target service serial number.
In the embodiment of the application, the billing data corresponding to the target service serial number is read from the second database according to the target service serial number. Of course, the invoicing data filling page can also be sent to the service end, the user fills the invoicing data, and the invoicing data returned by the service end is obtained.
307. And calculating bill information corresponding to the billing data based on the billing data.
Specifically, the tax surrogates are calculated according to the billing data, and the bill information is generated according to the tax surrogates. For example, the taxes calculating logic of the single piece of invoicing data is as follows: the typical tax = value added tax + urban construction tax + education addition + local education addition + personal tax + stamp tax, and the calculation logic may be set according to specific situations, which is not limited in the present application.
In a specific embodiment, the taxes surrogated corresponding to each serial number may be calculated in advance, the taxes surrogated corresponding to the serial numbers may be stored in the mysql database, and the taxes surrogated in the mysql database may be read when the mysql database is used. For example, a collection is automatically generated every day according to the received business data, the total collection of the collection tax each day is calculated, and the collection tax is displayed in a collection tax menu. The user can view the tax representative situation in the interface. The user confirms that the taxes of the representative are matched with the actual collected money, clicks 'confirmation', the system acquires a confirmation instruction of the user, and marks the service data of the representative batch as a 'settled' state. Acquiring business data corresponding to the serial number according to the serial number of the billing data, determining the tax surrogates according to the business data of the serial number, and generating bill information according to the calculated tax surrogates, wherein the bill information comprises the tax surrogates and settlement states.
308: and sending the bill information to the service end to confirm the bill information and judging whether to acquire confirmation information returned by the service end.
In a specific embodiment, the target service flow number is written into a first database; after the target service serial number is written into the first database, a timing task is set for the first database, wherein the timing task is as follows: and the first database deletes the target service serial number when the time for writing the target service serial number reaches the preset time. The first database may be a memory database such as Redis, mongoDB, SQLite, oracle, and the like. The memory database is a database which directly operates by putting data in a memory as the name implies. Compared with a magnetic disk, the data reading and writing speed of the memory is higher by several orders of magnitude, and the performance of the application can be greatly improved by storing data in the memory compared with accessing the memory from the magnetic disk. Redis (Remote Dictionary Server), which is a Remote Dictionary service, is an open-source log-type and Key-Value database written in ANSIC language, supporting network, based on memory and persistent, and provides API of multiple languages. redis is a key-value storage system. Similar to Memcached, it supports relatively more stored value types, including string, list, set, zset, and hash. These data types all support push/pop, add/remove, and intersect union and difference, and richer operations, and these operations are all atomic. On this basis, redis supports various different ways of ordering. As with memcached, data is cached in memory to ensure efficiency. The difference is that the redis can periodically write updated data into a disk or write modification operation into an additional recording file, and master-slave synchronization is realized on the basis of the update. Redis places more emphasis on process sequential writes, and although clustering is supported, is limited to master-slave mode. It is generally applicable to "performance and operation with a small amount of data, such as session storage in network development". MongoDB: the method is more suitable for cluster deployment, and can be generally used for improving the access efficiency of mass data analysis by considering more cluster schemes.
When the service end page initiates billing, a plurality of billing requests can be selected for billing. As the interface of the third party billing platform adopts an asynchronous interface and cannot return data in real time, the serial number of the initiated billing request is cached in the redis, a certain caching period is set, and the serial number is cleared when the time is out, so that billing can be initiated again. Therefore, the situation that the third party billing platform makes mistakes to cause that the billing result is not returned for a long time can be avoided, and the billing request of the invoice generation platform enters a 'dead' state. For example, according to the running time of the third-party billing platform, the preset time can be set to be 3 minutes, and billing can be initiated again after the serial number is written into the first database for 3 minutes. Specifically, when the serial number is written into the redis, the life cycle of the serial number is set to 3 minutes. Because the redis is single-threaded, under the condition of single-threaded, various lock problems do not need to be considered, the locking and releasing operation does not exist, and the performance consumption caused by possible deadlock can be avoided.
Specifically, it is determined whether to obtain the confirmation information returned by the service end, and if the confirmation information returned by the service end is obtained, the process is executed 309. If the confirmation information returned by the service end is not acquired, 312, rejecting the invoicing request is executed. Further, it is determined whether the confirmation information is obtained within a predetermined time, and if the confirmation information is not obtained within the predetermined time, the refund billing request is executed 312.
309: and sending the billing data to a third party billing platform for billing.
After receiving the bill information, the user of the service end confirms the bill information, and after confirming that the bill information is correct, clicks "confirm", the service end sends the confirmation information of the user to the invoice generation system 110, and the invoice generation system 110 obtains the confirmation information returned by the service end. When the invoice generating system 110 acquires the confirmation information returned by the service end, it indicates that the user confirms the invoice information, and can make invoices, and send the invoicing data to the third party invoicing platform for making invoices.
Specifically, the invoicing micro-service is used for sending an invoice printing request to a third-party invoicing platform based on invoicing data and waiting for invoicing information returned by the third-party invoicing platform. The invoice information can comprise invoice information and an invoice state, and the invoice information can be a printed electronic invoice. And the billing data corresponding to the plurality of target business serial numbers can be simultaneously sent to a third-party billing platform for billing.
310. And acquiring billing information returned by the third-party billing platform.
The billing information comprises billing state and invoice information. The billing state comprises successful billing and failed billing. The invoice information may include "date of invoice", "invoice type", "invoice status", "failure reason", "invoice code", "invoice number", and the like.
311. And sending the billing information to a service end, and calling uplink micro-service to write the billing information into a preset alliance chain.
And sending the billing information to a service end for downloading by a user.
In a specific embodiment, whether the billing state is successful is judged; and if the billing state is successful, sending billing information to the service end. And if the billing state is billing failure, acquiring the failure reason in the invoice information and sending the failure reason to the service end.
Furthermore, after the billing information returned by the third-party billing platform is acquired, the billing state corresponding to the target business serial number is updated to be 'billed'. And after obtaining the billing information, storing and calling the uplink micro service to uplink the billing information, and transferring the invoice state flow to the invoiced invoice. Thereby forming an invoice issuing service closed loop and preventing the issuing invoice from being out of control from the monitoring perspective.
When an inquiry instruction input by a user is obtained, acquiring an invoice code or an invoice number in the inquiry instruction, and calling an uplink micro-service to acquire service data corresponding to the invoice code or the invoice number from a preset alliance chain according to the invoice code or the invoice number. For example, according to a specific invoice issued by the tax control machine, an invoice code and an invoice number are provided, and a user finds out business data for issuing the invoice through the invoice tracing of the invoice generation system 110, including: cargo information, driver's information and vehicle information to realize that each invoice can both fix a position business information, prevent that the invoice from running falsely, promote the authenticity of invoicing.
In order to better implement the invoice generating method in the embodiment of the present application, on the basis of the invoice generating method, an invoice generating apparatus is further provided in the embodiment of the present application, as shown in fig. 4, fig. 4 is a schematic structural diagram of an embodiment of the invoice generating apparatus provided in the embodiment of the present application, and the invoice generating apparatus includes:
a first obtaining unit 401, configured to obtain a target billing request initiated by a service end;
a second obtaining unit 402, configured to obtain, based on the target billing request, a target service serial number corresponding to the target billing request;
a determining unit 404, configured to determine whether a target service serial number exists in a first database, where the first database is used to store a service serial number corresponding to a received billing request;
and an invoicing unit 405 configured to invoice the service end based on the target invoicing request if the target service serial number does not exist in the first database.
Optionally, the invoice generating apparatus further includes a basic data unit 403,
an invoicing unit 405, configured to obtain information to be verified corresponding to the target service serial number;
a basic data unit 403, configured to verify whether the information to be verified is correct;
a determining unit 404, configured to determine whether the target service serial number exists in the first database if the information to be verified is correct.
Optionally, an invoicing unit 405 configured to:
writing a target business serial number into a preset message middleware by using the invoicing micro service as a producer;
utilizing basic data micro service as a middleware for monitoring preset messages by a consumer;
and when the target service serial number in the preset message middleware is monitored through the basic data micro-service, acquiring to-be-verified information corresponding to the target service serial number.
Optionally, an invoicing unit 405 configured to:
acquiring billing data corresponding to the serial number of the target service;
sending the billing data to a third party billing platform for billing;
acquiring billing information returned by a third party billing platform;
and sending the billing information to a service end.
Optionally, an invoicing unit 405 configured to:
writing the target service serial number into a first database;
after the target service serial number is written into the first database, a timing task is set for the first database, wherein the timing task is as follows: and the first database deletes the target service serial number when the time for writing the target service serial number reaches the preset time.
Optionally, an invoicing unit 405 configured to:
calculating bill information corresponding to the billing data based on the billing data;
sending the bill information to a service end for bill information confirmation;
and when the confirmation information returned by the service end is acquired, the billing data is sent to a third party billing platform for billing.
Optionally, the billing information includes a billing status, and the billing unit 405 is configured to:
judging whether the billing state is successful;
and if the billing state is successful, sending billing information to the service end, and calling uplink micro-service to write the billing information into the preset alliance chain.
The embodiment of the application further provides an electronic device, which integrates any invoice generation device provided by the embodiment of the application. As shown in fig. 5, a schematic structural diagram of an electronic device according to an embodiment of the present application is shown, specifically:
the electronic device may include components such as a processor 501 of one or more processing cores, memory 502 of one or more computer-readable storage media, a power supply 503, and an input unit 504. Those skilled in the art will appreciate that the electronic device configurations shown in the figures do not constitute limitations of the electronic device, and may include more or fewer components than shown, or some components in combination, or a different arrangement of components. Wherein:
the processor 501 is a control center of the electronic device, connects various parts of the whole electronic device by using various interfaces and lines, performs various functions of the electronic device and processes data by operating or executing software programs and/or modules stored in the memory 502 and calling data stored in the memory 502, thereby integrally monitoring the electronic device. Optionally, processor 501 may include one or more processing cores; preferably, the processor 501 may integrate an application processor, which mainly handles operating systems, user interfaces, application programs, etc., and a modem processor, which mainly handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor 501.
The memory 502 may be used to store software programs and modules, and the processor 501 executes various functional applications and data processing by operating the software programs and modules stored in the memory 502. The memory 502 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data created according to use of the electronic device, and the like. Further, the memory 502 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device. Accordingly, the memory 502 may also include a memory controller to provide the processor 501 with access to the memory 502.
The electronic device further comprises a power source 503 for supplying power to each component, and preferably, the power source 503 may be logically connected to the processor 501 through a power management system, so as to implement functions of managing charging, discharging, and power consumption through the power management system. The power supply 503 may also include any component of one or more dc or ac power sources, recharging systems, power failure detection circuitry, power converters or inverters, power status indicators, and the like.
The electronic device may also include an input unit 504, and the input unit 504 may be used to receive input numeric or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.
Although not shown, the electronic device may further include a display unit and the like, which are not described in detail herein. Specifically, in this embodiment, the processor 501 in the electronic device loads the executable file corresponding to the process of one or more application programs into the memory 502 according to the following instructions, and the processor 501 runs the application program stored in the memory 502, so as to implement various functions as follows:
acquiring a target billing request initiated by a service end;
acquiring a target service serial number corresponding to the target billing request based on the target billing request;
judging whether a target service serial number exists in a first database, wherein the first database is used for storing the service serial number corresponding to the received invoicing request;
and if the target service serial number does not exist in the first database, invoicing is carried out on the service end based on the target invoicing request.
It will be understood by those skilled in the art that all or part of the steps of the methods of the above embodiments may be performed by instructions or by associated hardware controlled by the instructions, which may be stored in a computer readable storage medium and loaded and executed by a processor.
To this end, an embodiment of the present application provides a computer-readable storage medium, which may include: read Only Memory (ROM), random Access Memory (RAM), magnetic or optical disks, and the like. Stored thereon, is a computer program, which is loaded by a processor to execute the steps of any of the invoice generation methods provided by the embodiments of the present application. For example, the computer program may be loaded by a processor to perform the steps of:
acquiring a target billing request initiated by a service end;
acquiring a target service serial number corresponding to the target billing request based on the target billing request;
judging whether a target service serial number exists in a first database, wherein the first database is used for storing the service serial number corresponding to the received invoicing request;
and if the target service serial number does not exist in the first database, invoicing is carried out on the service end based on the target invoicing request.
In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and parts that are not described in detail in a certain embodiment may refer to the above detailed descriptions of other embodiments, and are not described herein again.
In a specific implementation, each unit or structure may be implemented as an independent entity, or may be combined arbitrarily to be implemented as one or several entities, and the specific implementation of each unit or structure may refer to the foregoing method embodiment, which is not described herein again.
The above operations can be implemented in the foregoing embodiments, and are not described in detail herein.
The invoice generation method, the invoice generation device, the electronic device and the storage medium provided in the embodiments of the present application are described in detail above, and specific examples are applied herein to explain the principles and embodiments of the present application, and the description of the embodiments is only used to help understand the method and the core idea of the present application; meanwhile, for those skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.

Claims (10)

1. An invoice generation method, characterized in that the invoice generation method comprises:
acquiring a target billing request initiated by a service end;
acquiring a target service serial number corresponding to the target billing request based on the target billing request;
judging whether the target service serial number exists in a first database, wherein the first database is used for storing the service serial number corresponding to the received billing request;
and if the target service serial number does not exist in the first database, invoicing is carried out on the service end based on the target invoicing request.
2. The invoice generation method according to claim 1, wherein the determining whether the target business serial number exists in the first database previously comprises:
acquiring information to be verified corresponding to the target service serial number;
verifying whether the information to be verified is correct or not;
and if the information to be verified is correct, judging whether the target service serial number exists in the first database.
3. The invoice generating method according to claim 2, wherein the obtaining of the to-be-verified information corresponding to the target business serial number comprises:
writing the target business serial number into a preset message middleware by using the billing microservice as a producer;
utilizing basic data microservices as consumers to monitor the preset message middleware;
and acquiring information to be verified corresponding to the target service serial number when the target service serial number in the preset message middleware is monitored through the basic data micro-service.
4. The invoice generation method according to any one of claims 1 to 3, wherein the invoicing the service terminal based on the target invoicing request comprises:
obtaining billing data corresponding to the target service serial number;
sending the billing data to a third party billing platform for billing;
acquiring billing information returned by the third party billing platform;
and sending the billing information to the service end.
5. The invoice generation method according to claim 4, wherein the sending the invoicing information to the service end, before, comprises:
writing the target service serial number into the first database;
after the target service serial number is written into the first database, a timing task is set for the first database, wherein the timing task is as follows: and deleting the target service serial number when the time written into the target service serial number reaches preset time by the first database.
6. The invoice generation method of claim 4, wherein the sending the invoicing data to a third party invoicing platform for invoicing comprises:
calculating bill information corresponding to the billing data based on the billing data;
sending the bill information to a service end for bill information confirmation;
and when the confirmation information returned by the service end is acquired, the billing data is sent to a third party billing platform for billing.
7. The invoice generation method of claim 4, wherein the invoicing information comprises an invoicing status, and the sending the invoicing information to the service end comprises:
judging whether the billing state is successful;
and if the billing state is successful, sending the billing information to the service end, and calling uplink micro-service to write the billing information into a preset alliance chain.
8. An invoice generating apparatus, characterized in that the invoice generating apparatus includes:
the first obtaining unit is used for obtaining a target billing request initiated by a service end;
a second obtaining unit, configured to obtain, based on the target billing request, a target service serial number corresponding to the target billing request;
the judging unit is used for judging whether the target service serial number exists in a first database, wherein the first database is used for storing the service serial number corresponding to the received invoicing request;
and the billing unit is used for billing the service end based on the target billing request if the target service serial number does not exist in the first database.
9. An electronic device, characterized in that the electronic device comprises:
one or more processors;
a memory; and
one or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor to implement the invoice generation method of any of claims 1 to 7.
10. A computer-readable storage medium, having stored thereon a computer program which is loaded by a processor to perform the steps in the invoice generation method of any one of claims 1 to 7.
CN202110477056.6A 2021-04-29 2021-04-29 Invoice generation method and device, electronic equipment and storage medium Pending CN115271835A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110477056.6A CN115271835A (en) 2021-04-29 2021-04-29 Invoice generation method and device, electronic equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110477056.6A CN115271835A (en) 2021-04-29 2021-04-29 Invoice generation method and device, electronic equipment and storage medium

Publications (1)

Publication Number Publication Date
CN115271835A true CN115271835A (en) 2022-11-01

Family

ID=83745183

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110477056.6A Pending CN115271835A (en) 2021-04-29 2021-04-29 Invoice generation method and device, electronic equipment and storage medium

Country Status (1)

Country Link
CN (1) CN115271835A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116385085A (en) * 2023-03-29 2023-07-04 北京融易算科技有限公司 Method, device and equipment for preventing invoice from being reissued

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116385085A (en) * 2023-03-29 2023-07-04 北京融易算科技有限公司 Method, device and equipment for preventing invoice from being reissued
CN116385085B (en) * 2023-03-29 2024-05-14 杭州融易算科技有限公司 Method, device and equipment for preventing invoice from being reissued

Similar Documents

Publication Publication Date Title
US11625700B2 (en) Cross-data-store operations in log-coordinated storage systems
US10296606B2 (en) Stateless datastore—independent transactions
US20180322149A1 (en) Automated configuration of log-coordinated storage groups
US10373247B2 (en) Lifecycle transitions in log-coordinated data stores
US10303795B2 (en) Read descriptors at heterogeneous storage systems
CN108874567B (en) Service processing method and system
KR20110000737A (en) Improvements relating to handling and processing of massive numbers of processing instructions in real time
CN101373474A (en) Magnanimity data real time processing structure and real time processing platform following with necessaries for the same
CN112286661B (en) Task scheduling method and device, storage medium and terminal
CN112579692A (en) Data synchronization method, device, system, equipment and storage medium
CN110880131A (en) Invoice generation method and device
CN110737510A (en) Block device management system
CN115271835A (en) Invoice generation method and device, electronic equipment and storage medium
CN113112344B (en) Service processing method, device, storage medium and computer program product
CN113051279A (en) Data message storage method, storage device, electronic equipment and storage medium
CN108121730B (en) Device and method for quickly synchronizing data update to service system
CN111581227A (en) Event pushing method and device, computer equipment and storage medium
CN111741080A (en) Network file distribution method and device
CN110827001A (en) Accounting event bookkeeping method, system, equipment and storage medium
CN105874435B (en) Non- block registration in distributed transaction
CN115858489A (en) Transaction processing method and device based on data migration, computer equipment and medium
CN112508710B (en) Account checking system and corresponding computer equipment
CN115617480A (en) Task scheduling method, device and system and storage medium
CN112162988A (en) Distributed transaction processing method and device and electronic equipment
CN107102901A (en) A kind of task processing method and device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination