CN112365300A

CN112365300A - Billing engine

Info

Publication number: CN112365300A
Application number: CN202011427642.1A
Authority: CN
Inventors: 陈丽园
Original assignee: Xiamen Sinoservices Information Technology Co ltd
Current assignee: XIAMEN SINOSERVICES INFORMATION TECHNOLOGY Co.,Ltd.
Priority date: 2020-12-07
Filing date: 2020-12-07
Publication date: 2021-02-12

Abstract

The invention provides a billing engine, which comprises a document module, is composed of a table structure, collects service data and document types and is used as an entrance for entering the billing engine. And the period charging module is used for generating a summary document according to the configured period and the summary rule. A reserved list module; and the data structure of the attribute of the reservation list is a two-dimensional array. The invention has the following beneficial effects: the documents are expressed through a table structure, the total undefined meaning attribute information of the business documents is defined through the document types, and the documents in any scene enter a charging engine through an entrance and are unified with a standard interface. The upstream system only needs to provide one service data defined according to the bill type information and appoint the bill type corresponding to the current service data, and the final cost can be obtained.

Description

Billing engine

Technical Field

The invention relates to the technical field of bill charging, in particular to a charging engine.

Background

The receipt is a written certificate which is obtained or filled in when economic business occurs and specifies the actual conditions of transaction and matters, and is the original material and important basis for accounting. With the complexity of the service types and the increase of the service volume, the charging rules of various industries are increasingly complex and diverse. Resulting in a new customer or supplier needing to sign a new set of billing rules and price table contracts. The charging mode is not fixed as before. In the prior art, a charging system needs to determine a formula according to a quotation in a contract and a charging rule, and after the formula is determined, a charging factor in charging in the formula is analyzed, and a bill table where the charging factor in butt joint with an upstream service system is located is designed. Then, a price table is made according to the contract price. And calculating through a bill table, a price table and a formula of the total charging factor in the code. Every time a new contract is added, a set of document table, a set of price table and a new formula for code writing are newly built in the database. Therefore, the current billing system needs enough interface adaptation, a large amount of document development and design of new formulas, which causes a dramatic increase in workload, and thus the operation and maintenance cost of the current billing system is extremely high.

Disclosure of Invention

The invention aims to provide a billing engine to solve the technical problems of high operation and maintenance cost and low calculation efficiency of the billing engine.

In order to achieve the purpose, the invention provides the following technical scheme:

a billing engine comprising

And the document module is formed by adopting a table structure, collects the service data and the document type and is used as an entrance for entering the billing engine.

The document module comprises a document type table and a business document table;

the business document of the business document table has 100 attribute information with undefined meanings;

the bill type of the bill type table is used for defining the meaning of the 100 pieces of attribute information;

the business document and the document type constitute document information.

The bill information comprises a charging factor required by a formula and service information required by display.

Wherein, the method also comprises the following steps,

and the period charging module is used for generating a summary document according to the configured period and the summary rule.

Wherein the period charging module comprises a period charging module,

the period configuration unit is used for defining a period through the cron code and obtaining period nodes of the time shaft; configuring timer nodes of a time axis through a timer; defining a final trigger time node;

the periodic task unit is used for acquiring periodic nodes from the last trigger time node of the timer to the trigger node of the current timer and generating a corresponding periodic task;

and the period default variable configuration unit is used for acquiring the documents in the time period according to the time period recorded in the period summary task, and performing summary operation to generate the summary documents.

Wherein, also include, reserve the tabulation module; and the data structure of the attribute of the reservation list is a two-dimensional array.

Wherein the reservation list module comprises

The rate detail head unit is used for defining reservation lists with different structures;

the rate detail attribute unit is used for defining attribute information of the reserved list;

and the rate detail attribute value unit is used for storing the value corresponding to the attribute information.

Wherein a redis cache is employed to process hot-point data.

Wherein, the long affairs in the code are divided into each subtask according to functions and CPU thread scheduling bias; the respective subtasks are notified via a message queue.

Wherein, the method comprises the steps of early-stage data preparation, mid-stage cost calculation and late-stage cost storage according to functions; the CPU thread scheduling bias is divided into compute intensive and IO intensive.

The invention has the following beneficial effects: the documents are expressed through a table structure, the total undefined meaning attribute information of the business documents is defined through the document types, and the documents in any scene enter a charging engine through an entrance and are unified with a standard interface. The upstream system only needs to provide one service data defined according to the bill type information and appoint the bill type corresponding to the current service data, and the final cost can be obtained.

Drawings

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

FIG. 1 is a schematic diagram of a periodic billing module of the present invention;

FIG. 2 is a cache schematic of the present billing engine;

FIG. 3 is a schematic diagram of a task message queue notification mechanism;

fig. 4 is a schematic diagram of a task message queue notification mechanism.

Detailed Description

The technical solutions of the present invention will be described clearly and completely with reference to the accompanying drawings, and it is to be understood that the described embodiments are only a part of the embodiments of the present invention, 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 invention.

Referring to fig. 1, a billing engine according to the present invention is illustrated, which includes a document module, which is composed of a table structure, including a document type table and a service document table. The business document of the business document table has 100 attribute information with undefined meanings; the bill type of the bill type table is used for defining the meaning of the 100 pieces of attribute information. The business document and the document type constitute document information. The bill information comprises a charging factor required by a formula and service information required by display. The charging factor required by the formula can also be called as a default variable, and the default variable is from the attribute information of the business document. The default variables also have simple grouping and summarizing functions, and are used for reducing the complexity of the formula. The bill type is not only used for defining the meaning of 100 attribute fields, but also is equivalent to an interface card for issuing a bill interface by an upstream system, the interface type for issuing the bill is fixed with 100 attribute information, a unified standard interface is achieved, and the bill in any scene enters a charging engine through an entrance. The upstream system only needs to provide two things, one is the business data defined according to the bill type information, and the other is the bill type corresponding to the specified current business data. The document module thus collects the business data and document type for entry into the billing engine.

In an alternative embodiment, as shown in fig. 1, the period charging module is configured to generate a summary document according to the configured period and the summary rule. The period charging module comprises a period charging module and a period charging module,

the period configuration unit is used for defining a period through the cron code and obtaining period nodes of the time shaft; the timer node of the time axis is configured through the timer, the timer only plays a role of triggering, the period can be free from the influence of the triggering of the timer, and the period can be traced and visualized; defining a final trigger time node;

and the period default variable configuration unit is used for acquiring the documents in the time period according to the time period recorded in the period summary task, performing summary operation to generate the summary documents, and finally calculating the cost through the charging engine logic by using the summary documents as the common documents.

In an optional embodiment, the system further comprises a reservation list module; and the data structure of the attribute of the reservation list is a two-dimensional array. The reservation list module comprises:

Each attribute value has corresponding row and column information, the information in the same row forms a reserved list record, and the information in the same column forms each value information of a certain attribute in the reserved list. This is done to maximize the flexibility of the reservation list. And the attribute value can be positioned through two dimensions, so that the reserved list can be matched quickly.

As in the following table:

a: price list data
			A [ Attribute field 1 ]][0]	A [ Attribute field 2 ]][0]	A [ Attribute field 3 ]][0]
A [ Attribute field 1 ]][1]	A [ Attribute field 2 ]][1]	A [ Attribute field 3 ]][1]
			A [ Attribute field 1 ]][2]	A [ Attribute field 2 ]][2]	A [ Attribute field 3 ]][2]
A [ Attribute field 1 ]][3]	A [ Attribute field 2 ]][3]	A [ Attribute field 3 ]][3]
			A [ Attribute field 1 ]][4]	A [ Attribute field 2 ]][4]	A [ Attribute field 3 ]][4]
A [ Attribute field 1 ]][5]	A [ Attribute field 2 ]][5]	A [ Attribute field 3 ]][5]
			A [ Attribute field 1 ]][6]	A [ Attribute field 2 ]][6]	A [ Attribute field 3 ]][6]
A [ Attribute field 1 ]][7]	A [ Attribute field 2 ]][7]	A [ Attribute field 3 ]][7]
			A [ Attribute field 1 ]][8]	A [ Attribute field 2 ]][8]	A [ Attribute field 3 ]][8]
A [ Attribute field 1 ]][9]	A [ Attribute field 2 ]][9]	A [ Attribute field 3 ]][9]
			A [ Attribute field 1 ]][10]	A [ Attribute field 2 ]][10]	A [ Attribute field 3 ]][10]

In an alternative embodiment, the formula is directly maintained and exposed in a pseudo code manner, which is equivalent to repackaging a layer of specific formula language on the basis of java language, and the function is repackaged under the formula language to make a special calculation, and the syntax of the formula language is as follows:

variables are as follows:

1. self-defining variables: self-defined variables

A modifier: $ $ fit for

Example (c): DEFIND $ unit price $ 0

SET $ unit price $ 100

2. Default variables are: the fields and values in the documents come from the corresponding documents

A modifier: []

Example (c): IF (origin) is equal to mansion gate

FOUND _ LIST ({ rate detail starting place } ═ starting place ], { rate detail unit })

EQUALS ([ origin ], mansion)

3. Reserved variable (reserved field): variable of rate dimension, value from reserved field value under rate

A modifier: {}

Example (c): IF (origin) is mansion gate

FOUND _ LIST ({ rate detail origin } - } ═ origin } - { rate detail unit price } -)

EQUALS ({ origin }, mansion door)

Constants are:

where a string that is not modified by any modifier is tasked with a constant, the value of the constant is itself.

Such as: 0 in DEFIND $ monovalent $ 0 is a constant

IF (origin) is constant as 'mansion door' in mansion door

It is noted that there are also default constants in the formula that represent special meanings, as follows

SYSDATE: the value of this constant is the system time

NOT _ FOUND: FOUND _ LIST returns this constant if no rate match is FOUND, and can be used to make decisions for other logic.

List:

1. default list: sub-lists inside documents, values from the corresponding document (one set), only FOR (recycle the list)

A modifier: [] The list names are placed in the modifier symbols, such as [ commodity details ], [ commodity details _ grouping ]

Example (c): FOR (commercial details)

IF $ maximum number of commodities $< [ details of commodities, quantity of commodities ]

The maximum number of commodities $ [ details of commodities, quantity of commodities ]

Wherein [ commodity details, commodity quantity ] refers to a default list field, and refers to a value of a field corresponding to each commodity detail under the FOR loop.

2. Reservation list (tariff details): LIST of rating dimensions, values from the rate detail LIST under the rating, only for the FIND _ LIST function

Modifier { }

Example (c): { origin of charge detail },' the preceding charge detail is fixed, specifying that the origin is a field within the charge detail and distinguishing reserved variables

Function:

FOUND _ LIST (arg1, arg 2): the cyclic matching rate detail function has similar function to the FOR, but simpler configuration

FOUND _ LIST will cycle through each record of the tariff details

arg 1: is a matching condition, can be participated in by the field of the tariff detail, or can not be participated in, and the returned result must be true or false

arg 2: is a match, FOUND _ LIST will stop cycling through the rate details if arg1 returns true, and the field of the current rate details line specified by arg2

Example (c): FOUND _ LIST ({ rate detail. origin }, { origin ] & & { rate detail. destination }, { destination ] | { rate detail. calculation method }, { rate detail. unit price })

Characteristic 1: if the FOUND _ LIST loop is full rate detail, but no one arg1 returns true, which is called no matching rate detail, the NOT FOUND constant is returned at this time.

Characteristic 2: the rating default condition mechanism is that if a certain field of rating is used as the judgment condition of arg1 and the value of this field is null (no value is given), then this judgment condition is defaulted. For expanding the probability of a match.

If a plurality of items are matched, wherein some items are matched only by the condition of default, the value corresponding to the tariff detail with the longest matching length is returned, and if the matching lengths are the same, the item with the larger line number is returned.

EQUALS (arg1, arg2) and NOT _ EQUALS (arg1, arg 2): a comparison function for judging whether two variables or constants are equal to each other

EQUALS indicates whether equal, NOT _ EQUALS indicates whether unequal, they return true or false

Example (c): IF EQUALS ($ unit price $, NOT _ FOUND)

SET $ unit price $ 10

Characteristic 1: equal/NOT _ equal can only be used to compare variables or constants of the same type, for example, $ unit price $ is a variable of a digital type, and NOT _ FOUND is a constant of a string type, and if the two are compared, they cannot be resolved, and at this time equal/NOT _ equal can be used for comparison.

Characteristic 2: equal/NOT _ equal is an extension of a function, two parameters are compared with each other, and if there is no result of comparison (error report), two parameters are compared with each other by a strong character string (uniform format).

3.SCALE(arg1,arg2,arg3)

arg1 is a fixed value, A or B

A: for exact decimal fraction scenario, when A, arg2 is a parameter (being a positive integer) specifying the exact decimal fraction of several digits

B: for carry system scenario, when B, arg2 is a parameter following several carries, which can be a decimal

arg3 is a number to be converted, and may be a constant, a custom variable, a default variable, a reserved variable

Example 1: processing the calculated amount by two decimal places

Return SCALE (A,2, [ total freight ])

Example 2: the weight of the charge is less than 10 by 10, less than 20 by 20, and so on

return SCALE (B,10, [ weight ])

4.LICH_KING(arg1)

This function is similar to FOUND _ LIST, except that FOUND _ LIST returns a specified field value, the value returned by lichking is an object, the value in the object can be used in subsequent formulas,

the advantages are no need of repeated matching, and the disadvantages are that many useless fields are taken out and occupy the memory

If the rate detail can NOT be FOUND, the NOT _ FOUND constant is returned for subsequent logic judgment

Example (c): set $ price subject $ ═ LICH _ KING ({ rate detail. origin } - } ═ origin ])

IF price object and calculation mode $ ═ ton

set $ unit price $ price object $.

The formula type: including DEFINE, FOR, IF/ELSE, SET, RETURN

DEFINE for a custom variable, the DEFINE-defined custom variable must be decorated with $ and must be given an initial value

Example (c): DEINE $ unit price $ 0

FOR is a FOR loop that loops through each record of the default list (the list decorated with [ ]), and loops through the sub-formulas under FOR.

Example (c): FOR (commercial details)

The characteristics are as follows: the FOR must be followed by a default list, where the field values recorded in the default list can only be used under the FOR sub-formula, otherwise no value can be taken.

IF/ELSE: is a logical judgment that the returned true or false senses whether to execute a sub-formula under IF

Example (c): IF EQUALS ($ unit price $, NOT _ FOUND)

SET $ unit price $ 10

ELSE

SET $ total price $ 0.17

SET for assigning custom variables

Example (c): DEFIND $ unit price $ 0

SET $ unit price $ 100

SET $ unit price $ FOUND _ LIST ({ rate detail. origin } ═ [ origin ] & { rate detail. destination } ═ destination ] | { rate detail. calculation mode } ═ calculation mode }, { rate detail. unit price })

RETURN refers to a RETURN value, where the value returned must be a number, which is used to generate a fee

The characteristics are as follows: if a charging rule is not executed in RETURN, the charging rule will not generate charge (for some situations the scenario of not generating charge)

Example (c): RETURN $ piece $ quantity $

Formula parsing exceptions include: code exception, normal check exception, expression analysis exception, and function execution exception.

1. Code exception: the stack exception is an exception caused by the defect and insufficient verification of the code, and the exception directly saves stack information into an exception record.

Example (c): null pointers, array cross-bounds, etc.

2. And (4) normally checking exception: the exception that the configuration data is not checked in the process of analyzing the formula is pointed, and the exception prompts information to be stored in an exception record.

Example (c): rates, formulas, rates details, and default variable configurations cannot be found.

3. The expression is analyzed abnormally: the method refers to an exception executed by an operational expression in a formula in an expression parser, such as addition, subtraction or comparison of numbers and character strings, which saves exception information into an exception record and also saves value information corresponding to variables and constants in the formula into the exception record.

Example (c): equation line 3: expression: the "P test (VALUE _ USD) VALUE _ Q" performs an exception.

4. Function execution exception: the method is characterized in that the exception of the formula function in the execution process is not necessarily error, and may be the verification of some characteristics in the function, and the exception does not exist in the exception record when the formula is normally executed, and only when the exception of the function causes other exceptions (the exception of the expression analysis), the exception record is existed together with the exception of the expression analysis.

Example (c): if the FOUND _ LIST does NOT find the rate, a NOT _ FOUND string is returned, and at the same time, a FOUND _ LIST execution exception record is generated.

At this time, the next line of formula will take the result returned by FOUND _ LIST to do calculation, because the character string is returned, the expression analysis exception will be generated when the calculation is executed

In the second case, if the result returned by FOUND _ LIST is not taken directly

Calculation is performed, whether the result is equal to NOT _ FOUND or NOT is judged, and the returned result is processed, so that the subsequent formula is NOT reported in error, and the abnormal function execution cannot be stored at the time

The flexible formula can satisfy the obstructed charging rules of the obstructed charging scenes

In an alternative embodiment, as shown in fig. 2, the charging engine uses a cache manner that a redis cache is used to process hot point data. By acquiring configuration data, acquiring configuration information, enabling the cache placed in the redis to survive for only 5 minutes, then returning to the information, judging whether the configuration exists in the redis, if so, continuing to complete service logic, otherwise, acquiring data from the database, and placing the acquired data in the redis.

In an alternative embodiment, as shown in fig. 3-4, the manner and servization of the charging engine to split the character includes dividing the long transaction into sub-tasks according to the functions and CPU thread scheduling bias in the code; the respective subtasks are notified via a message queue. According to functions, the method comprises the steps of early-stage data preparation, middle-stage cost calculation and later-stage cost storage; the CPU thread scheduling bias is divided into compute intensive and IO intensive. And distributing the more scientific thread number processed by the cpu according to the function of each task and the biased cpu scheduling mode, thereby maximizing the utilization of the cpu resources. And each task is respectively deployed to an unavailable server, and the hardware resources of the server are monopolized according to the biased cpu scheduling mode according to the function of each task, so that task service is realized.

The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present invention, and all the changes or substitutions should be covered within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A billing engine, characterized by: comprises that

2. A rating engine as claimed in claim 1, wherein: the document module comprises a document type table and a business document table;

the business document and the document type constitute document information.

3. A rating engine as claimed in claim 2, wherein: the bill information comprises a charging factor required by a formula and service information required by display.

4. A rating engine as claimed in claim 3, wherein: also comprises the following steps of (1) preparing,

5. The rating engine of claim 4, wherein: the period charging module comprises a period charging module and a period charging module,

6. A rating engine according to any of claims 1 to 5, wherein: the system also comprises a reserved list module; and the data structure of the attribute of the reservation list is a two-dimensional array.

7. The rating engine of claim 6, wherein: the reservation list module comprises

8. A rating engine according to any of claims 1 to 5, wherein: a redis cache is employed to process hot-point data.

9. A rating engine according to any of claims 1 to 5, wherein: dividing long affairs into each subtask according to functions and CPU thread scheduling bias in the codes; the respective subtasks are notified via a message queue.

10. A rating engine according to claim 9, wherein the division into early data preparation, mid-term charge calculation and late-term charge preservation according to function; the CPU thread scheduling bias is divided into compute intensive and IO intensive.