Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail and completely with reference to the following specific embodiments of the present application and the accompanying drawings. It should be apparent that the described embodiments are only some 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.
The technical solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.
In order to solve the problem that the complexity of checking is high due to the fact that the bill checking method in the prior art needs to know the internal generation logic of each type of bill, the embodiment of the specification provides the bill checking method. The execution subject of the bill verification method provided by the embodiment of the present specification may be, but is not limited to, a server and the like, which can be configured to execute at least one of the method apparatuses provided by the embodiment of the present invention.
For convenience of description, the following description will be made of an embodiment of the method, taking an execution subject of the method as a server capable of executing the method as an example. It is understood that the implementation of the method by the server is merely an exemplary illustration and should not be construed as a limitation of the method.
Specifically, an implementation flow diagram of a bill verification method provided in one or more embodiments of the present specification is shown in fig. 1, and includes:
step 110, extracting dimension data corresponding to the service bill to be verified, wherein the dimension data comprises first dimension data and second dimension data.
The first dimension data is used for matching a historical bill corresponding to a service bill to be verified, and the second dimension data is related to the first dimension data. The first dimension data can be obtained by extracting the service data based on the service to be verified, the target bill generation model used for generating the service bill to be verified in a matching mode and the historical bills of the same type generated through the target bill generation model, and can also be obtained by directly extracting the service bill to be verified, and the second dimension data is obtained by extracting the service bill to be verified.
It is to be understood that one or more first dimension data, and one or more second dimension data may be included in the dimension data. Any one of the second dimension data may be derived based on all or part of the first dimension data in the dimension data.
The second dimension data is related to the first dimension data in a number of ways. For example, some second dimension data may be obtained by performing logical operation processing on part of the first dimension data; for another example, the second dimension data may be obtained based on a mapping table of the first dimension data and the second dimension data. Of course, the embodiments of the present application do not exclude other implementations.
Optionally, the first dimension data comprises at least one of: payment code, payment amount, payment channel, account arrival mode and payment mode. The payment code is a payment two-dimensional code scanned when the user pays through the third-party payment application, or a payment two-dimensional code which is displayed to a merchant by opening the third-party payment application when the user pays; the payment amount is a specific amount paid by the user; the payment channel can comprise channels of on-the-spot payment, online payment and the like; the account-receiving mode comprises an instant account-receiving mode, a common account-receiving mode, a next day account-receiving mode and the like; the payment means may include balance payment, credit payment, monetary fund payment, and the like.
Optionally, the second dimension data comprises at least one of: the direction of charge; a rate; a collection account; a preference code; the product code is charged. The charging direction refers to an object paid by a user, namely a payee, and for example, when payment is made during shopping in the XX supermarket, the charging direction is the XX supermarket; the rate refers to a charging standard which is signed in advance by the merchant and the third party payment application; the collection account is used for collecting money by the merchant when the user pays the merchant through the third-party payment application; the discount code is a discount code corresponding to the discount acquired by the user when the merchant pays; the charging product code is the product code corresponding to the product purchased by the user at the merchant.
Optionally, in order to reduce the verification complexity of the service bill to be verified, that is, without knowing the internal generation logic thereof, one or more embodiments of the present specification may extract the dimension data corresponding to the service bill to be verified, match the corresponding target bill generation model with the first dimension data in the dimension data, generate the historical bill by using the target bill generation model, and compare the second dimension data in the dimension data corresponding to the service bill to be verified with the second dimension data in the historical bill, and may verify the accuracy of the service bill to be verified based on the comparison result, thereby avoiding knowing the internal generation logic of each type of bill, and simplifying the verification procedure.
When the service bill to be verified is verified, the dimensional data corresponding to the service bill to be verified needs to be extracted, which may specifically include:
acquiring service data of a service to be checked;
extracting first dimension data of the service to be verified based on the service data of the service to be verified;
determining a target bill generation model matched with the first dimension data;
the service data of the service to be verified is used as the input of a target bill generation model to obtain a service bill to be verified;
and extracting second dimension data of the service bill to be verified.
The service data of the service to be verified is original service data generated after a user completes one payment through a third-party payment application, and the service data comprises payment time, payment codes, payment amount, payment channels, payment users, an account arrival mode, a payment place and other data related to payment scenes of the user.
In order to extract useful data, namely first dimension data, from the business data, one or more embodiments of the present specification train a first dimension data extraction model in advance based on a large amount of historical business data, and the first dimension data extraction model can extract useful data from original business data as the first dimension data. Therefore, the first dimension data of the service to be verified is extracted based on the service data of the service to be verified, and specifically, the service data of the service to be verified can be used as the input of the first dimension data extraction model to extract the first dimension data of the service to be verified; the first dimension data extraction model is obtained by training service data based on a large amount of historical services.
In order to facilitate generation of corresponding bills based on the first dimension data of the service to be verified, one or more embodiments of the present specification may establish a corresponding bill generation model for each type of bill in advance, and each type of bill generation model may be marked by the first dimension data to distinguish different types of bill generation models. After the first dimension data is extracted from the service data of the service to be verified, different payment scenarios may correspond to different types of bills, and the first dimension data corresponding to the same type of bill is often the same. Therefore, a target bill generation model matched with the first dimension data can be determined based on the first dimension data, and the first dimension data of the service to be verified is used as an input of the target bill generation model to obtain the bill of the service to be verified.
As shown in fig. 2, for a schematic diagram of bill generation provided in the embodiment of the present specification, as can be seen from fig. 2, different merchants (i.e., payees) correspond to different subscription rate information, after business data of a service to be verified is obtained, first dimension data of the service to be verified may be extracted based on the business data of the service to be verified, and a matched target bill generation model may be determined according to the first dimension data, where the target bill generation model may include one or more rate calculation modes.
Since the information such as the payment code and the payment channel included in the first dimension data may be used to match a corresponding merchant, and different merchants may sign a charging standard, that is, rate information, in advance with the third-party payment application, the contracted rate information corresponding to the merchant may be determined based on the information of the merchant (that is, contracted pid, and there is a one-to-one mapping relationship between the contracted pid and the rate dimension shown in fig. 2, that is, one merchant corresponds to one contracted pid, and one contracted pid corresponds to one rate dimension).
Namely, the rate dimension corresponding to the signed pid can be determined, and finally, the first dimension data of the service to be verified is used as the input of the target bill generation model to generate the corresponding charging bill. As shown in fig. 2, the bill contents included in the charging bill generated based on the first dimension data of the service to be verified include: rate, charging direction, preferential code, expenditure account number, income account number and charging product code.
After the business bill to be verified is generated through the target bill generation model, there may be various dimension data included in the generated bill, and the dimension data of some dimensions in the information may be different for different users, such as the payment account, the payment time, and the like of the user. Therefore, in order to obtain the second-dimension data in the service bill to be verified, which can be used for comparison with the historical bill, one or more embodiments of the present specification may also train a second-dimension data extraction model in advance based on a large amount of historical bills. Then, second dimension data of the service bill to be verified is extracted, and specifically, the service bill to be verified can be used as an input of the second dimension data extraction model to obtain the second dimension data of the service bill to be verified.
Optionally, in one or more embodiments of the present description, the extracting the first dimension data and the second dimension data directly based on the service bill to be verified, and then extracting the dimension data corresponding to the service bill to be verified specifically includes:
acquiring service data of a service to be checked;
determining a target bill generation model matched with the service data of the service to be verified;
the service data of the service to be verified is used as the input of a target bill generation model to obtain a service bill to be verified;
and extracting the first dimension data and the second dimension data of the business bill to be verified.
The target bill generation model can directly establish a corresponding relation with the service data of the service to be verified in advance. The first dimension data and the second dimension data of the service bill to be verified are extracted specifically by a first dimension data extraction model and a second dimension data extraction model respectively.
And step 120, acquiring second dimension data in the historical bill matched with the first dimension data.
Optionally, in order to reduce the complexity of checking the bill and avoid knowing the internal generation logic of the bill to be checked when checking the bill, one or more embodiments of the present specification may obtain the historical bill matching the first dimension data of the service to be checked. The historical bill corresponding to the historical service of which the service to be verified is the same type is used as a reference bill, the reference bill can be a bill of the same type generated by the target bill generation model in the historical time period, and the reference bill passes accuracy verification after being generated. And then extracting second dimension data in the reference bill for comparison with the second dimension data in the bill to be verified.
Then, the obtaining of the second dimension data in the historical bill matched with the first dimension data may specifically include:
acquiring a historical bill matched with the first dimension data;
and extracting second dimension data in the historical bills.
The historical bills matched with the first dimension data can also be stored in advance by taking the first dimension data as a mark, so that matching calling can be performed through the first dimension data. And the second dimension data in the historical bill is extracted, specifically, the second dimension data can also be extracted through a second dimension data extraction model, that is, the historical bill is used as the input of the second dimension data extraction model, so as to obtain the second dimension data of the historical bill.
As shown in Table 1, examples of historical bills 1-2 and bills 1-2 of services to be verified are provided for one or more embodiments of the present specification. The first dimension data corresponding to the historical bill 1 with the service transaction time of 2017/10/15 comprises a payment channel (in-plane payment), an account arrival mode (instant account arrival), a payment mode (balance payment) and a payment account (user 1), wherein the bill content in the historical bill 1 comprises a charging direction (payee 1), a rate (1%), the payment account (account a), the payment account (account x) and a payment product code 1; the first dimension data corresponding to the historical bill 2 with the service transaction time of 2017/10/16 comprises a payment channel (in-person payment), an account-arriving mode (instant account-arriving) and a payment account (user 2), and the bill content of the historical bill 2 comprises a charging direction (payee 2), a rate (2%), the payment account (account b) and a payment account (account y).
The first dimension data corresponding to the to-be-verified business bill 1 with the business transaction time of 2017/10/17 comprises a payment channel (in-place payment), an account arrival mode (instant account arrival), a payment mode (balance payment) and a payment account (user 1), and the second dimension data corresponding to the to-be-verified business bill 1 comprises a charging direction (payee 1), a rate (1%), a payment account (account c), a collection account (account x) and a payment product code 2. The first dimension data corresponding to the service bill 2 to be verified with the service transaction time of 2017/10/17 comprises a payment channel (transfer account), an account arrival mode (instant account arrival) and a payment account (user 4), wherein the bill content in the service bill 2 to be verified comprises a charging direction (payee 2), a rate (2%), the payment account (account d) and a collection account (account y).
As shown in table 1, since the first dimension data corresponding to the service bill 1 to be verified matches the first dimension data corresponding to the historical bill 1, the historical bill 1 can be used as a reference bill for verifying the service bill 1 to be verified. And extracting second-dimension data in the historical bill 1 based on the historical bill 1 so as to compare the second-dimension data with the second-dimension data of the business bill 1 to be verified. Similarly, since the second-dimension data corresponding to the service bill 2 to be verified matches the first-dimension data corresponding to the historical bill 2, the historical bill 2 can be used as the reference bill of the service bill 2 to be verified. And extracting second-dimension data in the historical bill 2 based on the historical bill 2 so as to compare the second-dimension data with the second-dimension data in the business bill 2 to be verified.
Table 1 two types of billing examples
And step 130, determining the accuracy of the service bill to be verified based on the comparison result of the second dimension data of the service bill to be verified and the second dimension data in the historical bill.
Optionally, the determining the accuracy of the service bill to be verified based on the comparison result between the second-dimension data of the service bill to be verified and the second-dimension data in the historical bill specifically includes:
if the second dimension data of the service bill to be verified is matched with the second dimension data in the historical bill, the service bill to be verified can be determined to be accurate;
and if the second dimension data of the business bill to be verified is not matched with the second dimension data in the historical bill, determining that the business bill to be verified is inaccurate.
Continuing to take table 1 as an example, since the rate in the second-dimensional data in the service bill 1 to be verified is 2% and the rate in the second-dimensional data in the reference bill historical bill 1 is 1%, it is obvious that the rates of the two are not the same, it can be determined that the service bill 1 to be verified is inaccurate, and the target bill generation model corresponding to the service bill 1 to be verified should be checked in time. As can be seen from table 1, the second-dimension data in the service bill 2 to be verified is consistent with the second-dimension data in the reference bill historical bill 2, so that it can be determined that the service bill 2 to be verified is accurate.
When the service bill to be verified is verified, the dimension data corresponding to the service bill to be verified can be extracted firstly, the dimension data comprises first dimension data and second dimension data, the first dimension data is used for matching a historical bill corresponding to the service bill to be verified, the second dimension data is related to the first dimension data, and then the second dimension data in the historical bill matched with the first dimension data can be obtained; and finally, the accuracy of the service bill to be verified can be determined based on the comparison result of the second dimension data of the service bill to be verified and the second dimension data in the historical bill. The dimension data in the bill to be verified can be compared with the dimension data in the historical bills of the same type, so that the generation logic in the business bill to be verified does not need to be known, and the complexity of bill verification is greatly reduced.
Fig. 3 is a schematic structural diagram of a bill checking device 300 provided in the present specification. Referring to fig. 3, in a software implementation, the bill checking apparatus 300 may include an extracting unit 301, an obtaining unit 302, and a checking unit 303, wherein:
the extracting unit 301 is configured to extract dimension data corresponding to a service bill to be verified, where the dimension data includes first dimension data and second dimension data, the first dimension data is used to match a historical bill corresponding to the service bill to be verified, and the second dimension data is related to the first dimension data;
an obtaining unit 302, configured to obtain second dimension data in a historical bill matched with the first dimension data;
the checking unit 303 determines the accuracy of the service bill to be checked based on the comparison result between the second dimension data of the service bill to be checked and the second dimension data in the historical bill.
When the service bill to be verified is verified, dimension data corresponding to the service bill to be verified can be extracted through the extraction unit 401, the dimension data includes first dimension data and second dimension data, the first dimension data is used for matching a historical bill corresponding to the service bill to be verified, the second dimension data is related to the first dimension data, and then the second dimension data in the historical bill matched with the first dimension data is obtained through the obtaining unit 402; finally, the checking unit 403 determines the accuracy of the service bill to be checked based on the comparison result between the second-dimension data of the service bill to be checked and the second-dimension data in the historical bill. The dimension data in the bill to be verified can be compared with the dimension data in the historical bills of the same type, so that the generation logic in the business bill to be verified does not need to be known, and the complexity of bill verification is greatly reduced.
Optionally, in an embodiment, the extracting unit 301 is specifically configured to:
acquiring service data of a service to be checked;
extracting first dimension data of the service to be verified based on the service data of the service to be verified;
determining a target bill generation model matched with the first dimension data;
the service data of the service to be verified is used as the input of the target bill generation model to obtain the service bill to be verified;
and extracting second dimension data of the service bill to be verified.
Optionally, in an embodiment, the obtaining unit 302 is specifically configured to:
acquiring a historical bill matched with the first dimension data;
and extracting second dimension data in the historical bill.
Optionally, in an embodiment, the verification unit 303 is specifically configured to:
if the second dimension data of the business bill to be verified is matched with the second dimension data in the historical bill, determining that the business bill to be verified is accurate;
and if the second dimension data of the business bill to be verified is not matched with the second dimension data in the historical bill, determining that the business bill to be verified is inaccurate.
Optionally, in an embodiment, the extracting unit 301 is specifically configured to:
the service data of the service to be checked is used as the input of a first dimension data extraction model so as to extract the first dimension data of the service to be checked;
the first dimension data extraction model is obtained by training service data based on a large amount of historical services.
Optionally, in an embodiment, the first dimension data includes at least one of:
a payment code; a payment amount; a payment channel; an account-arriving mode; and (4) a payment mode.
Optionally, in an embodiment, the second dimension data includes at least one of:
the direction of charge; a rate; a collection account; a preference code; the product code is charged.
The bill verification apparatus 300 can implement the method in the embodiment of the method shown in fig. 1 to fig. 2, and specifically refer to the bill verification method in the embodiment shown in fig. 1 to fig. 2, which is not described again.
Fig. 4 is a schematic structural diagram of an electronic device provided in an embodiment of the present specification. Referring to fig. 4, at a hardware level, the electronic device includes a processor, and optionally further includes an internal bus, a network interface, and a memory. The Memory may include a Memory, such as a Random-Access Memory (RAM), and may further include a non-volatile Memory, such as at least 1 disk Memory. Of course, the electronic device may also include hardware required for other services.
The processor, the network interface, and the memory may be connected to each other via an internal bus, which may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one double-headed arrow is shown in FIG. 4, but that does not indicate only one bus or one type of bus.
And the memory is used for storing programs. In particular, the program may include program code comprising computer operating instructions. The memory may include both memory and non-volatile storage and provides instructions and data to the processor.
The processor reads the corresponding computer program from the nonvolatile memory into the memory and then runs the computer program to form the bill checking device on the logic level. The processor is used for executing the program stored in the memory and is specifically used for executing the following operations:
extracting dimension data corresponding to a service bill to be verified, wherein the dimension data comprise first dimension data and second dimension data, the first dimension data are used for matching a historical bill corresponding to the service bill to be verified, and the second dimension data are related to the first dimension data;
acquiring second dimension data in the historical bill matched with the first dimension data;
and determining the accuracy of the business bill to be verified based on the comparison result of the second dimension data of the business bill to be verified and the second dimension data in the historical bill.
The bill checking method disclosed in the embodiments of fig. 1-2 of the present specification can be applied to or implemented by a processor. The processor may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components. The various methods, steps and logic blocks disclosed in one or more embodiments of the present specification may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with one or more embodiments of the present disclosure may be embodied directly in hardware, in a software module executed by a hardware decoding processor, or in a combination of the hardware and software modules executed by a hardware decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.
The electronic device may further perform the bill checking method shown in fig. 1-2, which is not described herein again.
Of course, besides the software implementation, the electronic device in this specification does not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
In short, the above description is only a preferred embodiment of the present disclosure, and is not intended to limit the scope of the present disclosure. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of the present disclosure should be included in the scope of protection of one or more embodiments of the present disclosure.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.