CN108734457B - Refund method under unified cashing system - Google Patents
Refund method under unified cashing system Download PDFInfo
- Publication number
- CN108734457B CN108734457B CN201810296195.7A CN201810296195A CN108734457B CN 108734457 B CN108734457 B CN 108734457B CN 201810296195 A CN201810296195 A CN 201810296195A CN 108734457 B CN108734457 B CN 108734457B
- Authority
- CN
- China
- Prior art keywords
- transaction
- business
- data
- financial
- information
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 54
- 230000004044 response Effects 0.000 claims abstract description 32
- 238000012545 processing Methods 0.000 claims description 73
- 230000010354 integration Effects 0.000 claims description 13
- 239000000284 extract Substances 0.000 claims description 5
- 230000001186 cumulative effect Effects 0.000 claims 1
- 238000006243 chemical reaction Methods 0.000 description 24
- 238000010586 diagram Methods 0.000 description 24
- 238000007726 management method Methods 0.000 description 19
- 230000008569 process Effects 0.000 description 15
- 230000006870 function Effects 0.000 description 12
- 230000002159 abnormal effect Effects 0.000 description 9
- 238000012423 maintenance Methods 0.000 description 8
- 238000013475 authorization Methods 0.000 description 7
- 238000004519 manufacturing process Methods 0.000 description 7
- 238000004140 cleaning Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 238000012550 audit Methods 0.000 description 4
- 230000010365 information processing Effects 0.000 description 4
- 238000003672 processing method Methods 0.000 description 4
- 238000013519 translation Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 3
- 238000013523 data management Methods 0.000 description 3
- 230000000977 initiatory effect Effects 0.000 description 3
- 238000003860 storage Methods 0.000 description 3
- 230000002547 anomalous effect Effects 0.000 description 2
- 230000001174 ascending effect Effects 0.000 description 2
- 230000002354 daily effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 230000008014 freezing Effects 0.000 description 1
- 238000007710 freezing Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/12—Accounting
- G06Q40/125—Finance or payroll
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Theoretical Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention relates to a refund method under a unified cashing system, which comprises the following steps: receiving a refund request; inquiring original transaction information according to the original transaction number in the refund request; generating a transaction order in response to the original transaction number being consistent with the original transaction information; and issuing a refund payment request.
Description
Technical Field
The invention relates to the technical field of software, in particular to a refund method under a unified cashing system.
Background
Cloud platform based software services have been applied in various aspects of enterprise activities. However, for the existing enterprise software service, the business software and the financial software are still in mutually independent states, and lack of a connected channel forms an island of information, and brings about a plurality of inconveniences in event processing, information flow and daily management. Particularly for financial refund work, the business software and the financial software separated in the prior art cause the work of financial staff to become unusually heavy, and the operation efficiency of enterprises is affected.
Disclosure of Invention
Aiming at the technical problems in the prior art, the invention provides a refund method under a unified cashing system, which comprises the following steps: receiving a refund request; inquiring original transaction information according to the original transaction number in the refund request; generating a transaction order in response to the original transaction number being consistent with the original transaction information; and issuing a refund payment request.
The method as described above, further comprising determining whether the transaction balance of the original transaction number exceeds the current refund request amount in response to the original transaction number being consistent with the original transaction information.
The method as described above, wherein the transaction balance is the difference between the transaction amount of the corresponding transaction of the original transaction number and the sum of the accumulated refund amounts that have occurred.
The method as described above, further comprising generating a transaction request parameter in response to the primary transaction number matching the primary transaction result.
The method as described above, further comprising generating a transaction request parameter from the original transaction information in response to the original transaction number not matching the original transaction result.
The method as described above, further comprising generating a refund inquiry in response to the refund transaction exceeding a predetermined time and periodically polling the status of the refund transaction to be confirmed.
The method as described above, wherein generating the transaction order further comprises generating a GUID unique code and obtaining refund channel information; the cashier generates a transaction code of the refund transaction in the transaction pool, and stores the refund request information into the transaction pool; and generating a refund transaction order for refunds according to the refund channel information.
The method as described above, wherein the GUID unique code is used for database operations to improve retrieval efficiency.
The method as above wherein the GUID unique code comprises a time stamp.
According to another embodiment of the present invention, there is provided a cashier system including: a cash register service system for receiving refund requests from the business system or the financial data processing system; inquiring the original transaction information according to the original transaction number in the refund request; generating a transaction order in response to the original transaction number being consistent with the original transaction information; and a paymate interface for generating a refund payment request from the transaction order.
The system as described above wherein the checkout counter service system generates a unique transaction number in the transaction pool based on the refund request and returns the transaction number to the checkout counter front end.
The system as described above, wherein the checkout counter comprises a checkout counter database.
A system as described above, wherein the checkout counter service system comprises: the first cash register service module is used for interacting with the cash register database; and the second cash desk service module is used for receiving the payment request and the payment result and controlling the first cash desk service module to update the cash desk database.
The system as described above, the checkout counter database comprising: a transaction pool table for recording the status of transactions; a transaction request table for recording transaction requests; and a transaction result table for recording a transaction result corresponding to the transaction request.
The system as described above, the checkout counter database comprising: the transaction pool table comprises a transaction pool main table used for recording the state of the transaction; and a transaction pool sub-table for recording the status of the transaction request.
The system as described above, the checkout counter database comprising: and the refund request list is used for recording the refund requests existing in the database of the cash register.
Drawings
Preferred embodiments of the present invention will be described in further detail below with reference to the attached drawing figures, wherein:
FIG. 1 is a schematic diagram of an industrial and financial integrated system according to one embodiment of the invention;
FIG. 2 is a schematic diagram of a financial integration system data flow according to one embodiment of the invention;
FIG. 3 is a schematic diagram of the structure of a checkout counter according to one embodiment of the invention;
FIG. 4 is a schematic diagram of a checkout counter system implementation according to one embodiment of the invention;
FIG. 5 is a schematic diagram of a checkout counter system arrangement according to one embodiment of the invention;
FIG. 6 is a schematic diagram of a database structure of a checkout counter according to one embodiment of the invention;
FIG. 7 is a schematic diagram of a database flow according to one embodiment of the invention;
FIG. 8 is a schematic diagram of a financial data processing system in accordance with an embodiment of the invention;
FIG. 9 is a business and financial integrated management method according to one embodiment of the application;
FIG. 10 is a clearing reconciliation method in accordance with an embodiment of the application;
FIG. 11 is a flow diagram of abnormal financial data processing according to one embodiment of the present application;
FIG. 12 is a schematic diagram of a refund method according to one embodiment of the application;
FIG. 13 is a schematic diagram of a credential generation method according to one embodiment of the present application; and
FIG. 14 is a schematic diagram of a financial information processing method according to one embodiment of the application.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
In the following detailed description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments of the application. In the drawings, like reference numerals describe substantially similar components throughout the different views. Various specific embodiments of the application are described in sufficient detail below to enable those skilled in the art to practice the teachings of the application. It is to be understood that other embodiments may be utilized or structural, logical, or electrical changes may be made to embodiments of the present application.
The invention provides a business and financial integrated system, which is characterized in that a cash register is added on the basis of a business system and a financial system to provide data support for integrating business and financial under the condition of meeting payment requirements; the integrated integration of business, payment and financial systems is realized by adding the financial data processing system, so that the working efficiency of business and financial departments of enterprises can be greatly improved, and a technical foundation is provided for the fine management of the enterprises.
FIG. 1 is a schematic diagram of an industrial and financial integrated system according to one embodiment of the invention. As shown, the financial integration system 100 includes a business system 10, a cash register station 20, and a financial data processing system 30, a financial system 40.
The business system 10 includes a business system foreground 101 and a business system background 102. The business system foreground 101 provides various types of interfaces to interact with users. These interfaces include, but are not limited to, business interfaces: website interfaces (e.g., PC officer network), APP interfaces (APP), mobile phone web page end interfaces (M station), program interfaces in third party applications (e.g., weChat public number, weChat applet, payment application, etc.), etc.; financial interface: a tent system interface, a member balance system interface, a stored value card system interface, a V4 system interface, and the like.
The business system foreground 101 generates orders according to the user's operations on the interface. The order at least comprises business information and information to be paid. The traffic information includes, but is not limited to: one or more of an order number, a service type, service content, user information, and information of a service provider. The information to be paid includes, but is not limited to: one or more of amount to be paid, currency, etc. The business system front 101 sends a transaction request to the checkout counter according to the order.
The business system background 102 provides support for the business system foreground. The business system background 102 records orders submitted by users and extracts corresponding order data from the orders submitted by users.
The checkout counter 20 includes a checkout counter front end 201, a paymate interface 202, and a checkout counter service system 203. The checkout counter front end 201 receives a transaction request from the business system front end 101. The transaction request includes a portion of the transaction information as well as information to be paid, such as an order number and information to be paid. The cashier front end 201 provides a payment page for the user or the clerk, confirms information such as a payment channel, a payment mode, a payment amount and the like according to the operation of the user, calls the payment platform interface 202 to initiate a payment request to a third party payment platform, and receives a payment result and transaction details.
Paymate interface 202 is used to communicate with third party paymate, send payment requests, receive payment results and transaction details. Third party paytables include, but are not limited to: one or more of direct connection, aggregate payment, member balance, stored value card and the like; wherein aggregated payments include, but are not limited to: one or more of bank POS, unionpay shortcut, payment treasure, weChat payment, apply Pay, samsung Pay, huawei Pay and PayPal. It should be noted by those skilled in the art that some third party paymate platforms, such as member balance systems or stored value card systems, may be owned or operated by a common entity with the industry and financial integration system. For the checkout counter 20, these platforms may be considered external third party paystations.
The checkout counter service system 203 provides support for the checkout counter front end 201 and the paymate interface 202. Further, the checkout counter service system 203 provides transaction record services. Specifically, the checkout counter service system 203 receives the transaction request from the checkout counter front end 201, adds new transactions in the established transaction pool and provides each transaction with a unique transaction number, and records and updates the status of the transaction. According to one embodiment of the invention, one transaction request may correspond to a plurality of transaction numbers.
The checkout counter front end 201 receives the transaction number from the checkout counter service system 203, invokes the paymate interface 202 to issue a payment request to a third party paymate. According to one embodiment of the invention, the payment request includes at least a transaction number and other payment information. In some embodiments, the payment request may also include other information such as an order number.
According to one embodiment of the invention, before initiating the payment, payment information is displayed on the payment interface to enable the user to confirm the payment information again. The paymate interface 202 receives a payment request from the cashier front end 201, and sends the payment request to a corresponding third party paymate after format conversion according to the type of the payment channel. Further, paymate interface 202 receives payment results and sends the payment results to checkout counter front 201. Further, paymate interface 202 sends the payment results and transaction details to cash desk service system 203. The cashier service 203 updates the record based on the payment results and transaction details from the paymate interface 202. The cashier service 203 asynchronously sends the payment result and the transaction details to the business system background 102 of the business system.
Financial data processing system 30 includes a business database 301, a cleaning database 302, and a financial credential system 303. The business database 301 receives business data from the business system background 102 of the business system 10. The service data includes: order data, transaction data, and payment results. Wherein the order data includes business information or a portion thereof. The transaction data includes a transaction number, or a transaction number and transaction details, or a portion thereof. The clearing database 302 receives clearing data from third party paymate, i.e., periodically receives its pushed clearing data from a bank or member balance system. The financial document system 303 performs clearing and reconciliation by using the service data of the service database 301 and the clearing data of the clearing database, and creates a service document and a clearing document according to the requirements of the financial system.
Financial system 40 includes a credential database 401. The credential database 401 receives the clearing credentials from the financial credential system 303 of the financial data processing system 30.
Thus, the business and financial integration system of the present invention enables integration between business system 10 and financial system 40. Data sharing and process association are realized among all systems in the industry and finance integrated system, so that the operation efficiency of enterprises can be greatly improved, and better customer experience is brought to users.
The business and financial integrated system can be suitable for various business forms. For example, the business system of the present invention can be applied to various business states such as a vehicle renting system, a network vehicle contracting system, a take-away system, etc. One of the characteristics of these business forms is high transaction frequency, wide range of transaction sites, high requirements of customer experience, and great difficulty in financial data processing. Under the condition that the business system is separated from the financial system, the enterprise must invest a great deal of manpower to process mass business data and financial data generated every day, clear and check out financial, and make relevant financial certificates. This is one of the important reasons for the high operating costs of enterprises. In some embodiments of the financial integration system to which the present invention is applied, the independent unified checkout stations can accommodate the characteristics of the transaction frequency and the transaction location of these businesses. The financial data processing system can realize automatic clearing and reconciliation and manufacture of financial certificates through integration of business data and clearing data. This can greatly reduce the operating costs of the enterprise.
FIG. 2 is a schematic diagram of a financial integration system data flow according to one embodiment of the invention. To better illustrate the transfer of data between the various systems, paymate interface 202 of checkout counter 20 is shown separately. However, paymate interface 202 should still be considered part of checkout counter 20.
According to one embodiment of the invention, the checkout counter 20 further includes a checkout counter management module 204. The checkout counter management module 204 is used to support the configuration and management of the checkout counter 20 by the operation and maintenance personnel.
According to one embodiment of the invention, the checkout counter interfaces with an external data center 205, log service module 206, and APPID service module 207 to obtain relevant services. To better illustrate the streaming of data and the association of services, the data center 205, log service module 206, and APPID service module 207 are represented separately in fig. 2. In other embodiments of the invention, they may be integrated with one another as one or more entities providing a variety of service functions.
The data center 205 is used to provide login and authentication services to operation and maintenance personnel, such as customer service personnel or administrators. The data center 205 obtains login information of a person logging in the cash desk 20 from the cash desk front end 201 of the cash desk 20, and returns an authentication result to the cash desk front end 201 after authentication. The log service module 206 and the APPID service module 207 obtain log data and a key from the cash register service system 203 of the cash register 20, and provide a log service and an encryption key authentication service.
As shown, a user or store member of the business system 10 generates an order through the business system 10. In some embodiments of the present invention, the order for business system 10 includes an order generated by a user using a service provided by the business system, such as: about orders, rental orders, take-out orders, and the like. These orders, whether pre-paid or post-paid, may employ the financial integrated system of the present invention. This information is of interest to financial system 40. On the other hand, the orders for business system 10 also include orders generated using similar financial functions, such as stored-value card refill orders, stored-value card consumption orders, membership loyalty consumption orders, billing system variation orders, and the like. These orders do not involve clearing-up with the bank. However, variations in stored value card information, member information, or billing information related to these orders also require the accounting system to be cleared and related credentials made.
The transaction system 10 sends a transaction request to the checkout counter 20 according to the order. To reduce the burden of data transmission, the business system 10 sends only data in the order that is relevant to the transaction to the cash register 20. According to one embodiment of the invention, the transaction request comprises only the order number and the information to be paid, such as order number, payment means, payment amount, currency. Business system 10 sends business data including the order details to financial data processing system 30 to generate financial credentials. According to one embodiment of the invention, the traffic data comprises: order number, service code, user information, information of the provider, transaction number, payment method, payment amount, currency, etc. The small amount of data for the transaction request ensures high efficiency of transmission and a controllable range of load. More order data, transaction data and payment results are included in the business data. Although the data size is large, the real-time performance is not required, and a large burden is not imposed on the system. Moreover, the business data has enough information quantity to meet the requirements of follow-up business certificate making and clearing and checking, and financial staff can easily find the reason of clearing and checking failure when clearing and checking failure occurs, so that the working efficiency is improved.
Further, the checkout counter front end 201 of the checkout counter 20 sends the payment result to the business system in real time to inform the business system whether the payment was successful. Moreover, the checkout counter service system 203 of the checkout counter 20 also asynchronously sends the payment results and payment details to the business system. The method ensures the real-time performance of result feedback, and avoids information loss caused by transmission and other reasons, so that the service system can store complete information related to orders.
The financial data processing system periodically obtains credit data from third party payment authorities, including member balance systems. The financial data processing system uses the business data and the clearing data to make a clearing account, creates financial credentials (including business credentials and clearing credentials) and pushes them to the financial system 40.
It should be noted by those skilled in the art that the above data transfer process may fully illustrate the advantages of the industry and financial integration system of the present invention. According to the business and financial integrated system, a business system can cope with a large amount of burst traffic through cloud load balancing. Well-established techniques already exist in the prior art and are not described in detail herein. In the existing system, the cashing function is generally integrated with the service function to realize load balancing. However, since the business and finance are not corresponding to many projects, even two different systems are completely adopted, the system structure with both business and cashing functions becomes very complex, and it is difficult to provide more support in finance. The cash register desk is separated into independent systems in the financial integrated system, so the cash register desk also needs to solve the problem of load balancing. Therefore, the invention redefines the transaction request between the business system and the cash register, wherein the transaction request only comprises a small amount of data, thereby reducing the scale of data exchange between the two systems and avoiding frequent data exchange. On the other hand, the checkout counter of the present invention also takes corresponding service classification and load balancing measures (described in detail later). This allows the invention to accommodate a large number of bursty traffic as well, thereby increasing the stability of the system. Similarly, external support of data centers, journals, and APPID services also facilitates load balancing.
Unlike a checkout counter, the financial data processing system has a requirement for computational power but not high real-time requirements, and therefore does not need to take into account load balancing in particular. The data sent by the transaction system to the financial processing system is transaction data that includes transaction data from the cash register and payment results. The clearing data is also sent to the financial data processing system. The financial data processing system can be configured at the cloud end, and the computing capacity of the cloud end is utilized; or may be configured on a server within the enterprise.
Financial staff uses a financial system on an enterprise's internal server and can view the credentials in the credentials database. Further, financial staff may use the financial data processing system within the scope of authorization to conduct manual clearing reconciliation and manual production of financial credentials. Financial staff is generally not allowed to directly access the business system and the checkout counter. The financial data processing system may include corresponding interfaces to enable restricted querying of the business system and the checkout counter. Unnecessary authority authorization is avoided on the basis of ensuring that financial staff can obtain required information. Alternatively, the financial staff may obtain the required information by authorized operation staff. Therefore, the information security of the industry and finance integrated system can be further ensured.
Fig. 3 is a schematic diagram of the structure of a checkout counter according to one embodiment of the invention. FIG. 4 is a schematic diagram of a checkout counter technical implementation according to one embodiment of the invention. As shown, the checkout counter employs a layered architecture comprising: the cashier service T2/T1, the front end of the cashier T3 and the management of the cashier T3; wherein the cash register service T1 is embodied in the form of a business logic layer BLL in the cash register service T2/T1; the checkout counter database is embodied in the checkout counter service T2/T1 in the form of a data access layer DAL.
The checkout counter service T2/T1 is the core of the checkout counter. As shown, the business system 10 pushes a transaction request (1) by invoking a payment page provided by the checkout counter front end T3; the cashier front end T3 calls the cashier service T2 to push a transaction request (2), and calls the APPID service to finish authentication (3). The APPID service is used to authenticate the received data. And entering a payment stage after authentication is completed. The cashier service T2/T1 invokes the paymate interface 202 to push a payment request to the corresponding third party paymate (4), and returns the payment result and transaction details (5), invokes the APPID service to complete authentication (6). The cash desk service T2/T1 pushes payment results and transaction details to the business system 10 (7), invoking the log service to push log information (8). If the short message needs to be sent to the user, the cashier service T2/T1 calls the short message service (9) to inform the user. Thereby, the transaction is completed.
For a stored value card or a member credit or the like consumption order, the cashier front end T3 pushes order data to the payment platform interface 202 (10), the payment platform interface 202 returns a payment result and transaction details to the cashier front end T3 (11), the cashier service T3 calls the cashier service T2/T1 (12), and the cashier service T2/T1 calls the data processing service T2/T1 (13), so that three-level account updating is realized. The cashier service T2/T1 invokes the log service push log information.
For the management of operation and maintenance personnel on the cash register, the cash register management T3 calls the cash register service T2/T1 to finish the management of the cash register (14), calls the APPID service to finish authentication, and the cash register service T2/T1 calls the log service to push log information.
With reference to fig. 4, the configuration of the checkout counter service in a layered architecture is further described. As shown, the checkout counter may be divided into a user interface layer UI layer, a business logic layer BLL layer, and a data access layer DAL layer. In particular, the checkout counter front end T3 and the checkout counter management T3 may be considered to be at the UI level for interface presentation, acquisition and feedback of user information. For example, the checkout counter front-end T3 may provide a payment interface to the user and confirm the user's payment services. The cashier management T3 user provides interfaces for functions such as basic data management, transaction record inquiry, payment subsidy and refund to operation staff, such as customer service staff or administrators. The checkout counter services T2 and T1 may be considered to be at the business logic level. The checkout counter service T2 implements the main data processing functions of the checkout counter, including order payment, basic data management, transaction record inquiry, payment subsidy and refund, etc. Further, the checkout counter service T2 may invoke a data processing service of the checkout counter; or the data processing services of the checkout counter may be considered to be integrated in the checkout counter service T2. The checkout counter service T1 is a service related to a checkout counter database, for example a service developed based on the Entity Framework. By using the checkout counter service T1, the developer can get rid of SQL. In other words, the operation on the database can be completed without understanding the SQL. Thus, the cash register station of the present invention may be more flexible to develop and more adaptable. Even if parts of the database are changed, the checkout counter does not need to be redeveloped. Further, the checkout counter database, data center, log service, APPID service, and sms service may be considered to be at the data access layer DAL, or the T0 layer. Taking the cash register database as an example, the cash register database supports the storage of records such as transaction data, basic data management, transaction record inquiry, payment subsidy, refund and the like. According to one embodiment of the invention, the functionality of interacting with the log service may also be integrated into the checkout counter database to enable operations related to the log service by the checkout counter database.
FIG. 5 is a schematic diagram of a checkout counter arrangement according to one embodiment of the invention. As shown, the checkout counter front-end may be disposed on a client-side server farm of the front-end network. The front-end network is connected to the service system through a firewall 501, a load balancer 502, and a read-write separation system 503. The checkout counter service T2/T1 may be arranged on a public server farm of a public network, which is connected to the front-end network through a load balancer 504. The checkout counter database may be arranged on a database network that is connected to the public network through a read-write separation system 505. The checkout counter management T3 may be disposed on a management network of the enterprise. The management network is connected to the service system through VPN 506. The management network is further interconnected with the head-end network, the public network and the database network. By arranging the checkout counter over a plurality of networks and by means of a suitable load balancing system, the checkout counter of the invention is enabled to keep the system stable even when handling large amounts of bursty traffic.
FIG. 6 is a schematic diagram of a database structure of a checkout counter according to one embodiment of the invention. FIG. 7 is a schematic diagram of a database flow according to one embodiment of the invention. As shown in fig. 6, the database main storage tables are a main pool table and a sub pool table. The master transaction pool table reflects the status of the transaction, e.g., master transaction pool table s= (0-to-transaction, 1-transaction success, 2-transaction failure, 3-transaction timeout, 4-transaction cancellation). The transaction pool sub-table reflects the status of the transaction request, such as transaction pool sub-table s= (0-unsolicited, 1-solicited, 2-transaction successful, 3-transaction failed, 4-transaction timeout, 5-transaction cancelled, 6-repeat transaction). Accordingly, the database maintains a data center push master table and a data center push sub-table associated with the data center, both of which are connected to the transaction pool master table and the transaction pool sub-table.
For an existing request, the database maintains a transaction request information table and a refund request information table. Which are interconnected with the transaction pool main and sub tables. Further, the database maintains a table of payment request information including, but not limited to, a member balance payment request information table, an aggregated payment request information table, a wired POS payment request information table, a wireless POS payment request information table, and the like. Accordingly, the database maintains a table of payment result information including, but not limited to, a member balance payment result information table, an aggregated payment result information table, a wired POS payment return table, a wireless POS receive table.
Referring to fig. 7, four letters C, U, R, and D represent newly added C, modified U, read R, delete D, respectively; s: representing the status of the transaction. Order number: the cash register is not limited or specified as generated by the respective business systems. Transaction number: generated by a cash register, such as a transaction serial number. Payment number: generated by each paymate, if the paymate does not generate a payment number, a unique number having a reference meaning is taken, for example: the bank POS payment mode takes POS serial numbers. The same transaction in fig. 7 refers to the fact that the cash register station currently allows the main table of the transaction pool to have one transaction to be paid (state code is 0) and a plurality of requested transactions (state code is 1).
The transaction process at the checkout counter will be described in detail below with the change of the database as a clue. Transaction completion (including success, failure, timeout, cancellation) does not include transaction information return from request detection completion (click immediate payment) throughout transaction process 700. The method specifically comprises the following steps:
in step 701, a transaction request is entered, first, a transaction request table TradeRequest is searched according to a transaction type TradeType, order number OrderCoding and a transaction serial number JYLS;
in step 702, it is determined whether the transaction was initiated for the first time, if no record is found, if there is a record, it is not;
in step 703, if there is no record, a record is newly added to the request table TradeRequest; otherwise, go directly to step 707;
in step 704, after receiving the immediate payment confirmation, the main table DealTradeMain adds a record, and the state dealtatus is 0 to be transacted; the sub-table DealTradeChild is newly added with a record, and the state Status is 0 and is not requested
In step 705, the checkout counter automatically initiates a payment request to a third party channel. The details are as follows:
if the member balance transaction is performed, inserting a request record into the member balance request table, and modifying the sub-table DealTradechild state Status to be 1 requested;
If the current payment transaction such as WeChat, payment bank or bank card is performed, inserting a request record into the current payment request table, and modifying the sub-table DealTradechild state Status into 1;
if the wired POS transaction is performed, inserting a request record into the wired POS request table, and modifying the sub-table DealTradechild state Status into 1 requested;
if the wireless POS transaction is performed, inserting a request record into the wireless POS request table, and modifying the sub-table DealTradeChild state Status into 1;
after the third party payment is completed, the following actions are taken according to different circumstances, step 706:
if the member balance is transacted, a response record is inserted into the member balance return list, meanwhile, the sub-table DealTradechild state Status is modified according to the actual transaction result (2 success, 3 failure and 4 timeout), and the main table DealTradeMain state DealStatus is modified (1 success, 2 failure and 3 timeout)
If the current payment transaction such as WeChat, payment treasures or bank cards is carried out, a record is inserted into the current payment synchronous return table, the current payment asynchronous notification return table is inserted into a record, meanwhile, the state Status of the sub-table DealTradeChild is modified according to the actual transaction result (2 success, 3 failure and 4 timeout), and the state DealStatus of the main table DealTradeMain is modified (1 success, 2 failure and 3 timeout)
If the wired POS transaction is performed, a record is inserted into the wired POS return table, meanwhile, the sub-table DealTradeChild state Status is modified according to the actual transaction result (2 success, 3 failure and 4 timeout), and the main table DealTradeMain state DealStatus is modified (1 success, 2 failure and 3 timeout)
If the wireless POS transaction is performed, a request record is inserted into the wireless POS return table, meanwhile, the sub-table DealTradeChild state Status is modified according to the actual transaction result (2 success, 3 failure and 4 timeout), and the main table DealTradeMain state DealStatus is modified (1 success, 2 failure and 3 timeout)
In step 707, if there is a record that is not the first initiation, the main table DealTradeMain and sub-table dealtrademachild are looked up according to the main key TradeRequest id of the request table TradeRequest
If the main table and the sub-table are not recorded in step 708, processing according to the flow rules from step 704 to step 706;
if, at step 709, the main table DealTradeMain state dealstatus=1, the sub-table dealtrademachild state status=2 indicates success, jump to the corresponding success page;
in step 710, if the main table DealTradeMain state dealstatus=2 and the sub-table dealtrademachild state status=3 indicates failure, a record is inserted into the sub-table dealtrademachild, and the state Status is 0 and is not requested, and then processed according to the step 705 to 706 flow rules;
In step 711, if the main table DealTradeMain state dealstatus=3 and the sub-table dealtrademachild state status=4 indicates timeout, a record is inserted into the sub-table dealtrademachild, and the state Status is 0 and is not requested, and then processed according to the step 705 to 706 flow rules;
at step 712, if the main table DealTradeMain state dealstatus=0, the sub-table dealtrademachild state status=0 indicates unsolicited, processing is as follows:
if the transaction is not a wireless POS transaction, the request is not initiated to the third party payment, the original transaction information is updated, and then the transaction information is processed according to the step 705 to 706;
if the transaction is a wireless POS transaction, judging that the time difference= (the current time of the system-the time CreateTime of the DealTradechild creation time) is less than 120 seconds, prompting that 'the wireless POS transaction is ready to be paid, please return to the service system for checking', otherwise prompting whether to cancel the transaction;
at step 713, if the main table DealTradeMain state dealtatus=0, the sub-table DealTradeChild state status=1 indicates that a request is made, i.e. a third party payment is in progress, prompting whether to cancel the original transaction;
ending the flow if the option is not cancelled at step 714;
at step 715, if cancel is selected, the main table and sub-table are re-queried; if the current main table DealTradeMain state Satus is not equal to 1, the main table state is 0, the record with sub-table state 1 is changed to be 5, and then the record is cancelled and processed according to the step 705 to 706;
If cancellation is selected and the original transaction continues at step 716, the sub-table DealTradeChild state Status is modified to 6 for repeated transactions and the master table state DealStatus is updated to 1 after success according to the asynchronously pushed transaction request single number matching the sub-table record.
In step 717, if the original transaction request is successful, searching the corresponding transaction pool sub-table record according to the transaction request number;
at step 718, if sub-table s=1, then this indicates that the transaction was successful;
if the sub-table S is not equal to 1, then the representative does issue a repeat transaction, modifying the sub-table DealTradechild state Status to 6 repeat transactions, and updating the master table state DealStatus to 1, at step 719.
According to one embodiment of the invention, the order pool master table has only one transaction order message per transaction request. The sub-table has a plurality of transaction records, which correspond to different transaction requests respectively, but the normal success state status=1 is only one, and a plurality of pieces of repeated transaction success information status=6 can be provided.
According to one embodiment of the invention, all updated pool sub-table transaction states and pool master table transaction states are noted: if the main table of the transaction pool is successful status=1, only the sub table state of the transaction pool is updated, and the main table state of the transaction pool is not updated.
FIG. 8 is a schematic diagram of a financial data processing system in accordance with an embodiment of the invention. As shown, the financial data processing system includes a business database 801, a clearing database 802, a clearing reconciliation module 803, a business credential module 804, a clearing credential module 805, and a credential pushing module 806.
The traffic database 801 is used to receive traffic data from a traffic system. The business data includes order data, transaction data, and payment results. According to one embodiment of the invention, the business system needs to include order details every time the business system pushes data to the financial data processing platform. According to one embodiment of the invention, the traffic data comprises: information such as business type, order number, user information, service provider information, service location, transaction time, transaction amount, transaction status, payment channel, payment number, payment mode, currency, etc.
The clearing database 802 is used to receive clearing data from third party paymate. The clearing data includes bank clearing data and member balance clearing data. For example, the clearing data of the bank includes information such as a bank code, a total amount, a clearing date, a transaction number, an amount, a commission fee, a transaction date, and the like. The member balance clearing data includes information such as payment member information, collection member information, service type, clearing date, transaction number, amount, commission, transaction date, etc.
The clearing and reconciliation module 803 is configured to implement an automatic or manual clearing and reconciliation function. Specifically, the clearing account is checked out by clearing data provided by a third party payment mechanism and business flow details.
For example, the bank may check out according to the following rules: the transaction amount of a certain transaction number in the clear and fine data provided by the bank is compared with the transaction amount of the transaction number in the business system; if the amounts are equal, the corresponding clear and fine account checking of the transaction number is consistent, namely the account checking is successful; if the amounts are not equal, the corresponding clear and fine account checking of the transaction number is not equal, namely the account checking fails.
For example, the reconciliation of member balances may be performed according to the following rules: the member balance checking is divided into summary checking and detail checking. If the transaction number data is summarized and checked successfully and the detail is checked successfully, the balance of the member of the transaction data is cleared and checked successfully; if the transaction number data is summarized and checked or the detail checking fails, the balance of the member of the transaction data is cleared and checked to fail.
For summary account checking, comparing the transaction amount of a certain transaction number in clear and clear data provided by member balance with the transaction amount of the transaction number in service system data, if the transaction amounts are equal, the clear and clear summary account checking corresponding to the transaction number is consistent, namely the account checking is successful; if the amount is not equal, the clearing summary account corresponding to the transaction number is not flat, namely the account checking fails.
For detail account checking, after clearing and summarizing account checking symbols corresponding to a certain transaction number, carrying out detail account checking of the transaction number, and respectively checking whether the real charging amount, the real storing amount and the rebate amount are equal; the real charging amount, the real storing amount and the rebate amount are respectively equal, and the clearing account checking corresponding to the transaction number is successful; if the corresponding amounts are respectively different, the clearing and checking account corresponding to the transaction number is not flat, and the checking account fails. Of course, if the summary of certain transaction data is classified as not being flat, the data is not subjected to detail reconciliation.
The service credential module 804 is configured to make a service credential according to the service data. Service credentials include, but are not limited to: pre-receipt credentials, revenue credentials, refund credentials, recharge credentials, stored value card sales payment credentials, stored value card expiration credentials, and the like.
The clearing voucher module 805 is configured to make a clearing voucher according to the checking result of the clearing checking module 803. The clearing vouchers include clearing data provided by third party payment authorities and their corresponding business details, including but not limited to bank clearing vouchers and member balance clearing vouchers.
For example, the bank clearance voucher includes: the information such as the bank code, the sum amount and detail amount data, the matched order number, the payment number, the transaction time, the clearing time, the server information and the like. The member balance clearing certificate comprises information such as summary data, detailed data, real charging, real storage amount, transaction time, clearing time, member information and the like.
The voucher pushing module 806 pushes the business voucher and the clearing voucher to the financial system. According to one embodiment of the present invention, the service credential module 804, the clearing credential module 805, and the credential pushing module 806 may be configured uniformly as one credential production module or in other configurations. These configurations are within the scope of the present invention.
Thus, the financial data processing system implements the functions of automatically clearing reconciliation and financial credential production. The financial staff's work burden can be greatly reduced to this, improves work efficiency, reduces the cost of enterprise. More importantly, for the business scene of the mobile internet, the financial data processing system is separated from other systems without facing a large amount of burst data, so that the smooth operation of the system is ensured, and the burden of enterprises is reduced.
Fig. 9 is a business and financial integrated management method according to an embodiment of the present invention. The method comprises the following steps:
at step 901, receiving a transaction request from a business system;
at step 902, payment is completed with the cash register and a payment result is returned to the business system;
in step 903, receiving traffic data from a traffic system;
receiving clearing data from a third party paymate at step 904;
At step 905, clearing reconciliation is performed at the financial data processing system utilizing the received order data and transaction data and the clearing data;
at step 906, a financial instrument is made at the financial data processing system using the received order data and transaction data and the clearance data; and
at step 907, financial credentials are pushed to the financial system.
Fig. 10 is a clearing and reconciliation method in accordance with an embodiment of the invention, comprising the steps of:
in step 1001, clearing data is received from a third party paymate. The clearing data includes bank clearing data received from a bank or member balance clearing data received from a member balance system. The bank or member balance system may send the clearance data to the financial data processing system on a periodic basis (e.g., daily). Those skilled in the art will appreciate that other sources of cleaning data are possible depending on the type of business of the enterprise.
Table 1 is an example of bank clearance data according to one embodiment of the invention:
in step 1002, traffic data is received. The business data includes order details data, transaction data, and payment results. According to one embodiment of the invention, the business data includes order details data to enable the business logic module to make business logic therewith, to check out, and to enable financial staff to query the order details in most cases to determine the reason for failure to check out successfully to provide efficiency.
Table 2 is an example of traffic data according to one embodiment of the invention:
in step 1003, the traffic data is matched with the score data. If the business data is consistent with the clear score data for one transaction, the matching is successful; otherwise, the matching fails. According to one embodiment of the invention, by "reconcile" is meant that the transactions are reconciled and the amounts are reconciled. For example, if data directed to the same transaction is included in both the business data and the clear data, the data directed to the transaction in the business data and the clear data may be considered to be transaction-compliant data. If the amount of the business data is the same as the amount of the clearing data in the transaction-compliant data, the transaction-compliant data amount can be considered to be compliant. Thus, the matching can be considered to be successful.
The method for matching the business data and the clearing data is described in detail below by taking clearing account of the bank clearing data and the member balance clearing data as an example. It will be appreciated by those skilled in the art that other types of score data may also be performed in a similar manner as compared to the two scores.
In some embodiments of the invention, the matching of bank clearance data may be performed as follows:
At step 1010, selecting a transaction number in the bank clearance data;
in step 1011, the transaction number is found in the transaction data;
in step 1012, in response to finding the transaction number in the transaction data, comparing the transaction amount corresponding to the transaction number in the bank clearance data with the transaction amount corresponding to the transaction number in the transaction data;
in step 1013, in response to the transaction amount corresponding to the transaction number in the bank clearing data being equal to the transaction amount corresponding to the transaction number in the service data, the clearing and detail reconciliation corresponding to the transaction number is consistent, i.e. the matching is successful;
in step 1014, in response to not finding the transaction number in the transaction data or the transaction amount corresponding to the transaction number in the bank clearance data is not equal to the transaction amount corresponding to the transaction number in the transaction data, no transaction details corresponding to the transaction number or the clearance details corresponding to the transaction number are not flat, i.e. the matching fails.
Those skilled in the art will appreciate that the index employed by the above clearing reconciliation is the transaction number. Other identifications in the bank clearance data may also be used as an index to perform the clearance reconciliation, such as a reference search number. Of course, the index should also be included in the traffic data.
In some embodiments of the present invention, for a pre-authorization service, it is treated as a separate transaction, reconciled using the transaction number of the pre-authorization service that was originally swiped. Subsequent consumption is also considered a separate transaction, reconciled using the transaction number at the time of consumption. In some embodiments of the invention, the refund business is not considered a separate transaction. When matching is performed, the transaction number which is time-consuming is cancelled by using the original brush for checking. And for refund of the pre-sale business, the transaction number of the pre-sale business is brushed for checking. Such setting can ensure smooth progress of the matching.
In some embodiments of the present invention, the matching of member balance clearance data may be performed as follows:
selecting a transaction number for clearing data at the member balance at step 1020;
in step 1021, the transaction number is found in the transaction data;
in step 1022, in response to finding the transaction number in the service data, comparing the summarized amount corresponding to the transaction number in the member balance clearing data with the summarized amount corresponding to the transaction number in the service data;
in step 1023, in response to the sum corresponding to the transaction number in the member balance clearing data being equal to the sum corresponding to the transaction number in the service data, comparing the respective subentry amounts under the sum;
In step 1024, in response to the sum of the transaction numbers in the member balance clearing data being equal to the sum of the transaction numbers in the business data, the clearing and detail accounting corresponding to the transaction numbers is consistent, i.e. the matching is successful; wherein the individual itemized amounts include, but are not limited to: the actual charging amount, the actual storing amount, the return amount, etc.
In step 1025, the transaction number corresponds to a clear and fine reconciliation that does not match, i.e., the match is unsuccessful, in response to:
1. the transaction corresponding to the transaction number is not found in the business data;
2. the corresponding sum of the transaction number in the member balance clearing data is not equal to the sum of the transaction number in the service data;
3. any one of the sub-item amounts under the summarized amount corresponding to the transaction number in the member balance clearing data is not equal to the corresponding sub-item amount under the summarized amount corresponding to the transaction number in the service data.
Those skilled in the art will appreciate that the index employed by the above clearing reconciliation is the transaction number. Other identifications in the bank clearance data may also be used as an index to perform the clearance reconciliation, such as a reference search number. Of course, the index should also be included in the traffic data.
In some embodiments of the invention, the member balance system may have a more complex structure, may include more itemized amounts, and may have more complex calculation rules. In order to improve the efficiency of clearing and checking the balance of the member, clearing and checking can be performed only for the last transaction of the same member. If the last transaction clearing reconciliation is a match, then only the aggregate amount may be compared against the previous clearing reconciliation without having to compare the itemized amounts. If the last transaction clearing reconciliation is not matching, then clearing reconciliation continues for the last transaction, and so on.
At step 1004, the matched traffic data is associated with the cleaning data. The matched business data and the clearing data are data which are successfully checked by automatic clearing. And correlating the matched business data with the clearing data, thereby completing clearing and checking.
In step 1005, unmatched business data and clear data are displayed. The automatic clearing and checking method is simple and convenient, and most clearing and checking works can be automatically completed, but partial business data and clearing and checking data are not matched. These cases will be classified as cases where abnormal financial data is present.
The reasons for the mismatch between the business data and the clear data may be caused by the difference in the presence of records in the business system or the banking system. For example, for a certain transaction number, it only appears in the transaction data/score data, and the score data/transaction data lacks a corresponding match. Or, for a certain transaction number, the transaction data and the data matched with the transaction in the clearing data are in a state that the amount is not matched.
The reason for the mismatch between the traffic data and the clear data may also be a formal problem. For example, a transaction number or amount may be subject to a format error, such as a transaction number or amount preceded by a number of "0" s or spaces, a transaction number followed by a space, an amount being subject to a position error, etc. These forms of problems may also cause the financial data processing system to fail to automatically complete the reconciliation.
For anomalous financial data, financial staff may manually associate business data with clearing data for manual clearing reconciliation. Therefore, in the step, unmatched business data and clearing data are displayed so as to realize subsequent manual clearing and checking.
At step 1006, the business data is manually associated with the score data. As previously introduced, in this step, the financial staff manually associates the business data with the clearing data, enabling manual clearing reconciliation. The financial staff compares the service data which are not matched with the clear score data, and determines the reason of the failure. If the reasons for the failure to match are format problems and the like, financial staff can associate business data with financial data in a financial data processing system to finish manual clearing and checking.
FIG. 11 is a flow diagram of abnormal financial data processing according to one embodiment of the present invention. For anomalous financial data, the financial staff may perform manual reconciliation. Further, for abnormal financial data caused by different records of the business system or the banking system, the financial staff needs to inquire the reasons for the different records.
According to one embodiment of the present invention, an abnormal financial data processing method includes the steps of:
in step 1101, business data and clearing data that fail to automatically match during the clearing reconciliation process are presented. In some embodiments, the business data and the score data are displayed in two columns and ordered according to the same rules. For example, the business data and the clearing data are both arranged in ascending or descending order according to the transaction number. Further, the business data and the clearing data with the same transaction number can be in the same or close horizontal position in the two columns, so that the financial staff can conveniently process the business data and the clearing data. Of course, the business data and the score data may also be ordered in other ways, such as by transaction time.
The financial staff inspects the business data and the score data which fail to be automatically matched, and the process goes to the steps 1102 and 1105 or 1108 according to different conditions.
At step 1102, business data and clearing data that automatically match during the clearing reconciliation process are presented. In some embodiments, the reason that the business data and the clearing data fail to match is that the financial data processing system associates erroneous business data and clearing data when automatically clearing the reconciliation. Thus, financial staff may need to cancel the wrong auto-match results when doing manual reconciliation. In some embodiments, the business data and the score data are displayed in two columns and ordered according to the same rules. For example, the business data and the clearing data are both arranged in ascending or descending order according to the transaction number. Further, the business data and the clearing data with the same transaction number can be in the same or close horizontal position in the two columns, so that the financial staff can conveniently process the business data and the clearing data. Of course, the business data and the score data may also be ordered in other ways, such as by transaction time.
At step 1103, the association between the traffic data and the cleaning data is canceled. After verification, the financial staff find the wrong automatic matching, and the wrong automatic matching can be canceled in the step.
At step 1104, the business data is manually associated with the score data. After the financial staff cancels the mismatching, the financial staff can return to the unmatched page again, and the business data and the clearing data are manually associated, so that manual clearing and checking are realized.
In step 1105, for the score data for which the transaction number is not queried in the transaction data, a log associated with the transaction number is queried. In some embodiments of the invention, the log generated by the checkout counter upon completion of the transaction may be stored in a separate log service module or database of the checkout counter. Since the transaction numbers are generated sequentially in the pool maintained by the checkout counter, there will be a corresponding log for each transaction number. The financial staff can know the detailed process of the transaction and the reason that the information corresponding to the transaction number is not sent to the business system by inquiring the corresponding log. Further, the financial staff can thereby learn the reason why the information corresponding to the transaction number is not forwarded to the financial data processing platform and the reason why the transaction number is recorded by the bank or member balance system. In particular, the financial data processing system may include a first query interface through which a financial person may enter query information (e.g., a transaction number) to issue a request to a log service module or a database of cash registers. After receiving the request, the log service module or the cashier station invokes the corresponding log and sends the log to the financial data processing module for financial staff to browse. According to one embodiment of the invention, the log service module or the cashier database, or the financial data processing system, comprises a log translation module. As logs may be difficult for non-technicians to understand. The log can be translated into a form which can be understood by financial staff or business staff through a log translation module for presentation. For reasons pertaining to the checkout counter or business system, go to step 1106; otherwise, go directly to step 1109.
In step 1106, the transaction data corresponding to the transaction number is generated and associated with the clearing data corresponding to the transaction number. Because of the reason of the cashier desk or the service system, the service data corresponding to the transaction number is not sent to the financial data processing system, financial staff can manually combine the transaction data corresponding to the transaction number with the order detail data to generate the service data, and manually complete the association of the service data and the clearing data.
In step 1107, for the case where the transaction number matches but the amount does not, a log associated with the transaction number and an order for the business system is queried. In some embodiments of the invention, the log generated by the checkout counter upon completion of the transaction may be stored in a separate log service module or database of the checkout counter. The financial staff can know the detailed process of the transaction and the transaction amount by inquiring the corresponding log. The specific steps are similar to step 1105 and will not be described again. Further, financial staff can query the business system to obtain more business aspect information. In particular, the financial data processing system may include a second query interface through which a financial person may input query information (e.g., a transaction number) to issue a request to the business system. And after receiving the request, the business system invokes the corresponding order and sends the order to the financial data processing module for financial staff to browse. For reasons pertaining to the business system or the checkout counter, go to step 1108; otherwise, go to step 1109.
In step 1108, the transaction data corresponding to the transaction number is modified and associated with the clearing data corresponding to the transaction number. Because of the reason of the cashier or the service system, the service data amount corresponding to the transaction number is not in accordance with the clearing amount, financial staff can manually modify the order detail data or the transaction data corresponding to the transaction number to generate new service data, and manually complete the association of the service data and the clearing data.
At step 1109, unmatched score data is derived. For clearing data where this portion fails to match, the reason for the mismatch may be a problem with the bank or member balance system. This portion of the score data may be derived. The exported data may be sent back to the bank or member balance system.
According to another embodiment of the invention, the financial staff is not authorized to query the business system and the checkout counter. The financial data processing system need not include a first query interface and a second query interface. After step 1104, the financial data processing system exports business data and clearance data that fail to match nor find a cause and sends these exported data to the operation and maintenance personnel. The operation and maintenance personnel have higher authority and can inquire the service system and the cash desk system. The operation and maintenance personnel inquire the orders and transaction logs corresponding to the exported data. If the reasons for the failure are the reasons for the business system or the cash register, the operation and maintenance personnel make corresponding modifications and then push the modified business data to the financial data processing system for automatic clearing and checking. Alternatively, the operation and maintenance personnel return the content to the financial personnel. The financial staff uses this information to make a manual clearing and checking account. For reasons that fail to match, which do not belong to the business system or the cashier, the financial staff derives it and returns it to the bank or member balance system.
The tracking and correcting of abnormal financial data is a work which cannot be completed by the existing financial system or business system, and often requires financial staff to contact a business department in a telephone or email mode to check orders and payment conditions, and is time-consuming, labor-consuming and extremely low in efficiency. Business data (including order details and transaction data) as well as clearing data have been included in the financial data processing system of the present invention. For most abnormal financial data, the financial staff is already able to determine the source of the problem based on the data already in the financial data processing system and make a manual clearing check. Further, the financial data processing system may include an interface for querying information related to the business system and the cash register to further obtain information related to the abnormal financial data from the business system and the cash register, so that a financial staff can find a reason that the business data and the clear data cannot be matched, and thus, the abnormal financial data is processed.
Fig. 12 is a schematic diagram of a refund method according to one embodiment of the invention. The refund application can be provided by the user, and the refund request can be initiated after the business system checks that the refund condition is met. Or, the financial staff find that the situation of refund is needed through clearing and checking, and the financial staff can initiate a refund request. According to one embodiment of the invention, the refund method comprises the steps of:
In step 1201, a refund request is received. The cashier station, as a subject to perform refunds, may receive refund requests from the business system or the financial data processing system (financial staff).
In step 1202, the original transaction information is queried according to the original transaction number in the refund request; and compares the transaction information in the refund request with the original transaction information of the query. The checkout counter first determines whether the original transaction number in the refund request matches the transaction information in the refund request. The cashier queries the transaction information stored in the cashier according to the original transaction number in the refund request, and compares the queried transaction information with the transaction information in the refund request. If the result of the comparison is inconsistent, the refund request is returned directly.
In step 1203, in response to the original transaction number being consistent with the original transaction information, it is determined whether the transaction balance of the original transaction number exceeds the current refund request amount. The original transaction number may have a refund occurred. The difference between the transaction amount of the corresponding transaction of the original transaction number and the sum of the accumulated refund amounts is the transaction balance of the original transaction number. If the transaction balance is less than the refund request amount, indicating that the refund request is stored incorrectly, directly returning the refund request. According to one embodiment of the invention, refunds that have occurred, i.e., refund requests that have actually completed refunds, are also included as refunds that are in progress but are made earlier in time than the current refund request.
In step 1204, a transaction order is generated in response to whether the transaction balance of the original transaction number exceeds the current refund request amount. After steps 1202 and 1203, the refund request has passed the audit of the checkout counter, which generates a refund transaction ticket and starts executing refund operations. According to one embodiment of the invention, the checkout counter stores refund information and generates a GUID unique code and obtains refund channel information. The GUID unique code is used for database operation, so that the speed of database retrieval can be increased. Further, the cashier generates a transaction code of the refund transaction in the transaction pool, and stores the refund request information in the transaction pool. Then, a refund transaction order for refunds is generated based on the refund channel information.
In step 1205, generating a transaction request parameter in response to the matching of the original transaction number and the original transaction result, and issuing a refund transaction request; and generating transaction request parameters according to the original transaction information and issuing a refund transaction request in response to the mismatch of the original transaction number and the original transaction result. The cashier determines the correct transaction request parameters by verifying the corresponding relation between the original transaction number and the original transaction result, so as to send out a refund request of a refund transaction order. If the original transaction number does not match the original transaction result, e.g., the transaction result corresponding to the original transaction number in the refund request is a timeout and the original transaction result recorded by the cash register is successful, then it is possible that the transaction request parameter is incorrect. Thus, the checkout counter generates transaction request parameters with the original transaction information and issues a refund transaction request to a third party payment mechanism or member balance system.
According to one embodiment of the present invention, in the event of a refund from a member balance system, it is also desirable to consider whether the member balance transaction is in a state where the balance is frozen. And if the member is not in the balance freezing state in the member balance system, sending a refund request by using a balance refund special interface. If the member is in the frozen state of the balance in the member balance system, the frozen state of the balance of the member can be temporarily withdrawn through the frozen state of the balance of the member and the withdrawal interface, and then refund is completed.
As previously mentioned, a refund transaction is also considered to be one of the transactions. The checkout counter processes the transaction in a similar manner as the consumer transaction. Taking the embodiment described in the embodiment of fig. 7 as an example, refund transactions also have their own transaction numbers and are handled in the same manner as other types of transactions in the transaction pool.
In step 1206, a refund transaction result is received in response to the refund transaction being successful. Further, the cash register station may asynchronously feed back the transaction results to the business system.
In step 1207, in response to the refund transaction failing, the process transitions to manual processing.
In step 1208, in response to the refund transaction exceeding a predetermined time (e.g., 1 minute), the checkout counter generates a refund inquiry and periodically polls the status of the refund transaction to be confirmed. The third party payment mechanism or member balance system feedback time may be relatively long because the third party payment mechanism or member balance system may also need to audit refund transactions. Thus, still keeping it in the transaction pool may take up excessive system resources. Thus, the checkout counter repeatedly confirms the refund transaction status by a task polling mechanism alone until the transaction is successful/unsuccessful.
FIG. 13 is a schematic diagram of a credential generation method according to one embodiment of the invention. As shown, the credential generation method includes the steps of:
in step 1301, traffic data is received. The business data includes order details data, transaction data, and payment results. According to one embodiment of the invention, the business system may integrate the order details data, transaction data and payment results into business data and send to the financial data processing system. An example of traffic data is shown in table 2.
Table 3 is an example of tent-type traffic data according to one embodiment of the present invention:
| name of the name | Type(s) | Description of the invention |
| Prepayment | Text + number | (slightly) |
| Pre-paid | Text + number | |
| Deposit | Text + number | |
| Pre-authorization | Text + number | |
| Fee collection at present | Text + number | |
| Pair rotary | Text + number | |
| Refund | Text + number | |
| Deduction money | Text + number | |
| Internal settlement | Text + number |
Table 4 is an example of service data of a member balance system according to one embodiment of the present invention:
| name of the name | Type(s) | Description of the invention |
| Service code | Text of | (slightly) |
| Order number | Text of | |
| Service serial number | Text of | |
| Transaction number | Text of | |
| Payment member ID | Text of | |
| Transaction date | Text of | |
| Transaction amount | Text of | |
| Payee ID | Text of | |
| Transaction type | Text of | |
| Payment number | Text of | |
| Payment mode | Text of |
In step 1302, a service credential is made from the service data. According to one embodiment of the invention, the business voucher includes, but is not limited to, a pre-receipt voucher, a revenue voucher, a refund voucher, and a member charging voucher. The content of the service voucher will vary depending on the specific requirements of the financial system. In some embodiments, the service credentials include, but are not limited to, the following: order number, service type, member ID, service provider, service commodity, charge amount, charge details, transaction type, transaction number, payment channel, payment method, etc.
According to one embodiment of the present invention, the making of the service credential may specifically include the steps of:
at step 1320, data is extracted from the business data. The financial data processing system extracts the required data from the service data in the service database according to the requirements of the service credentials.
At step 1321, the extracted data is converted according to a conversion table. The translation table includes, but is not limited to: the service system comprises a service system architecture conversion table, a basic data conversion table and a service code conversion table. The financial data processing system converts the data through a conversion table. The settings for the organization, underlying data, and business codes in the financial system may vary from business system to business system. Moreover, business systems are also much more frequent than financial systems due to the need for adjustment. Thus, many of the business data, such as organizations, underlying data, and business codes, are not directly understood by the financial system. The function of each conversion table is to translate business data into data that can be understood by the financial system.
Taking the service system architecture conversion table as an example, a transaction may be displayed in the service data from a second store in south kyo. And only Nanjing branch is present in the financial system. Therefore, it is necessary to convert the second store in south kyo in the business data to south kyo corporation using the organization structure conversion table. The converted data can generate the certificate financial data which can be understood, and then the certificate which becomes the compliance is checked.
Taking the basic data conversion table as an example, the type of transaction that may be displayed in the business data is "stored value card rebate". Such transactions in financial systems are classified as "internal transaction not payable". Thus, it is necessary to translate "stored value card rebate" into "internal transaction not collect" using the underlying data conversion table.
Taking the service code conversion table as an example, the service code in the service data, which may show a transaction, is "DZ03", which represents a short rental service for a certain large customer. However, the finance system classifies such services as a short rental service DZ. Therefore, it is necessary to translate "DZ03" into "DZ" using the service code conversion table.
Those skilled in the art will appreciate that the three types of conversion tables above are for illustrative purposes only. The type and form of the conversion table are not limited to these three types. For example, transaction types, payment methods, payment channels, etc. may also be converted using similar conversion tables. Another advantage of introducing a conversion table is that a channel of communication is established between the business system and the financial system that are independent of each other. Whether it is an update of a business system or a financial system, only the conversion table needs to be modified to enable new associations.
At step 1322, business credentials are generated and pushed to the financial system. The financial data processing system may directly use the converted data to generate business documents. The financial data processing system may push the generated business voucher to the financial system on an immediate or regular basis. According to one embodiment of the invention, the business logic can be pushed to different destinations according to rules for realizing financial records of actual economic transactions and financial management.
In step 1323, in response to the service credential pushing failure, the converted data is presented. The service credential may fail the audit of the financial system if the push fails. By exposing the converted data to the financial staff, the financial staff can learn the reasons for failing the audit and modify the credentials.
At step 1323, the service credential is manually generated. The financial staff may manually generate the business voucher after viewing. Further, financial staff can manually push business certificates to the financial system, and feedback of the financial system can be obtained in real time. Thus, the production and pushing of the business certificate are realized.
Turning to step 1302, in step 1303, a result of successful clearing and reconciliation is received. And for the clearing data of which the clearing reconciliation is successful, the financial data processing system generates clearing credentials.
In step 1304, a clearing voucher is made according to the result of successful clearing and reconciliation. The clearing certificates comprise a bank clearing certificate and a member balance clearing certificate. According to one embodiment of the present invention, a method of making a clearing voucher may include the steps of:
at step 1340, data is extracted from the score data. The financial data processing system extracts data required for manufacturing the clearing certificate from clearing data of which clearing checking is successful.
In step 1341, the extracted data is converted according to a conversion table. The translation table includes, but is not limited to: the bank/member balance system constructs a conversion table, a basic data conversion table, and a business code conversion table. The function of the conversion table for converting the clear data is similar to that of the conversion table for converting the service data, and will not be described again.
At step 1342, a clearing voucher is generated and pushed to the financial system. The financial data processing system uses the converted data to generate a clearing certificate and pushes it to the financial system either instantaneously or periodically. According to one embodiment of the invention, the clearing credentials may be pushed to different destinations according to rules for effecting financial records of actual economic transactions and financial management.
In step 1343, the converted data is presented in response to the push failure. At this step, the financial person may view and modify the data in the clearing voucher.
At step 1344, a clearing voucher is manually generated. Financial staff manually generates a clearing certificate, and the manually generated clearing certificate can be pushed to a financial system in real time. Based on feedback from the financial system, the financial staff is allowed to modify the clearing voucher again and push again until the push is successful.
The financial data processing system integrates order data, transaction data, and clearance data, and is the center for data collection. The independent financial data processing system does not need to bear the strict requirements of a business system and a cash register on real-time performance, does not need to bear the strict confidentiality and authority requirements of the financial system, becomes an important tool for assisting the financial system to realize the functions of clearing and checking accounts and generating financial certificates, reduces the cost of enterprises, and improves the operation efficiency of the enterprises.
FIG. 14 is a schematic diagram of a financial information processing method according to one embodiment of the invention. In the existing system with separated business system and financial system, the business system and the financial system operate according to their respective processes, and the problems of untimely information update or difficult information tracking often occur. In the industry and finance integrated system, the invention provides an event-driven financial information processing method, which specifically comprises the following steps:
In step 1401, a first identifier is assigned in response to the occurrence of a financial event. According to the embodiment of the invention, the occurrence of the financial event can be used for driving the operation of the financial integrated system, processing the financial related information and synchronizing the starting point of each system data. In some embodiments of the invention, financial events include, but are not limited to: consumption events, transaction subsidy events, pre-authorization events, member recharge events, member return events, and refund events.
The consumption event includes the user using the service provided by the enterprise and paying the corresponding fee, which includes the user directly paying by using a tool such as a bank card, a payment bank, a WeChat, an AplyPay, or paying by using a member balance/stored value card. The transaction subsidy event includes the entry of a transaction subsidy into the system by an enterprise employee when the user does not enter the transaction into the business system in real time using cash payment or other reasons. The pre-authorization event includes the assurance that the user will obtain a subsequent payment in a pre-authorized manner prior to the user's actual payment, such as when using a credit card. The member recharge event includes a user recharging an amount to a stored card or member balance. The refund event is directed to the user or member balance/stored value card refund amount. Those skilled in the art will appreciate that the above are just some examples of financial events. The financial integration system of the present invention may include more or no other financial events.
When a financial event occurs, a first identifier is assigned to the financial event. The first identifier includes information such as an order number, a service serial number, a composite code (service type + place code + time of occurrence), and the like. When the information backtracking is needed, the financial event corresponding to the first identifier and the detailed information of the financial event can be determined according to the first identifier.
In step 1402, a transaction request including a first identifier is received, a second identifier is assigned, and a payment request including the first identifier and the second identifier is generated. When a financial event occurs, a transaction request is generated to initiate payment to a third party paymate (including a member balance system). As a requirement for financial information processing and data tracking, payment with third party paytables (including member balance systems) also needs to be recorded. The second identifier is assigned prior to initiating the payment request. One example of a second identifier is a transaction number. It will be appreciated by those skilled in the art that other identifiers capable of distinguishing between payment requests may also be used as the second identifier. The payment request includes the first identifier and the second identifier, i.e. may include an order number and a transaction number. According to one embodiment of the invention, one first identifier may correspond to a plurality of second identifiers. For example, one order number may correspond to multiple transaction numbers.
In step 1403, a payment request is initiated and a payment result is received that includes a third identifier. The third identifier, such as a payment number or a retrieval reference number, is an identifier generated by a third party paymate (member balance system). After receiving the payment request, the third party payment platform (member balance system) allocates a payment number for the allocation request and returns a payment result including the payment number. According to one embodiment of the invention, the second identifier or the first identifier and the second identifier are also included in the payment result.
In step 1404, business data is generated based on the financial event and the payment result; wherein the service data comprises at least a second identifier. Business data is data pushed by the business system to the financial data processing system, including data required by the financial data processing system to make a clearing check, including, but not limited to, data related to financial events and data related to transactions, and payment results. To clarify the reconciliation, the business data comprises at least a second identifier. According to an embodiment of the invention, the service data also comprises the first identifier and/or the third identifier.
At step 1405, the clean up data is received, the clean up data including at least a second identifier. The clearing data is from a third party paymate (including a member balance system). The clearing data reflects payment activity transmitted through third party paymate (including member balance systems) validation. To reconcile with the business data, the clearing data should include at least a second identifier. According to an embodiment of the invention, the clearing data also comprises the first identifier and/or the third identifier.
In step 1406, the transaction data and the clearing data are utilized to make a clearing reconciliation. The second identifier or other identifier is used to match the cleaning data with the corresponding business data. If the two match, the clearing and checking are successful. For a specific way of clearing the reconciliation, reference may be made to the previous description.
In step 1407, in response to the clearing reconciliation being successful, a clearing credential is made and sent to the financial system. By sending the clearing certificate to the financial system, the processing of the whole-flow financial information from the business system to the financial system is realized, and a bridge is established between the business system and the financial system. If the clearing and reconciliation is unsuccessful, the financial staff can query the financial event and the corresponding transaction and payment behavior of the financial event by using the second identifier or other identifiers, so that the reason of the unsuccessful reconciliation can be known and corresponding processing can be performed.
The above embodiments are provided for illustrating the present invention and not for limiting the present invention, and various changes and modifications may be made by one skilled in the relevant art without departing from the scope of the present invention, therefore, all equivalent technical solutions shall fall within the scope of the present disclosure.
Claims (14)
1. The utility model provides a cash desk refund method under unified receipts silver-colored system, is applied in industry financial integration system, industry financial integration system includes: business system, cashier desk and financial data processing system, financial system;
the business system comprises a business system foreground and a business system background, wherein the business system foreground provides various interfaces to interact with a user;
the business system foreground generates an order according to the operation of a user on the interface, wherein the order at least comprises business information and information to be paid, and the business information comprises: one or more of order number, service type, service content, user information, and service provider information, the information to be paid including: one or more of the amount to be paid and the currency information, and a business system foreground sends a transaction request to a cash register according to the order;
the service system background provides support for the service system foreground, records orders submitted by users, and extracts corresponding order data from the orders submitted by the users;
the cashier comprises a front end of the cashier, a payment platform interface and a cashier service system, wherein the front end of the cashier receives a transaction request from the front end of the business system, the transaction request comprises a part of business information and information to be paid, the front end of the cashier provides a payment page for a user or a clerk, a payment channel, a payment mode and payment amount information are confirmed according to the operation of the user, the payment platform interface is called to initiate a payment request to a third party payment platform, and a payment result and a transaction detail are received;
The payment platform interface is used for communicating with a third party payment platform, sending a payment request, and receiving a payment result and transaction details;
the cashier service system provides support for the front end of the cashier and the payment platform interface, the cashier service system provides transaction recording service, the cashier service system receives a transaction request from the front end of the cashier, adds new transactions in the established transaction pool, provides unique transaction numbers for each transaction, and records and updates the state of the transaction;
the front end of the cash register receives the transaction number from the cash register service system, and invokes a payment platform interface to send a payment request to a third party payment platform;
the financial data processing system comprises a business database, a clearing database and a financial credential system, wherein the business database receives business data from a business system background of the business system, and the business data comprises: the order data comprises business information or a part of the business information, the transaction data comprises a transaction number or a transaction number and a transaction detail or a part of the transaction number, the clearing database receives clearing data from a third party payment platform, the financial evidence system carries out clearing and checking by utilizing the business data of the business database and the clearing data of the clearing database, and a business evidence and a clearing evidence are manufactured according to requirements of the financial system;
The financial system includes a credential database that receives a clearing credential from a financial credential system of the financial data processing system;
the method comprises the following steps:
receiving a refund request from a business system;
inquiring original transaction information according to the original transaction number in the refund request;
generating a refund transaction order in response to the transaction information in the refund request being consistent with the original transaction information; and
sending out refund payment request;
wherein generating the refund transaction ticket further comprises generating a GUID unique code and obtaining refund channel information; the cashier generates a transaction code of the refund transaction in the transaction pool, and stores the refund request information into the transaction pool; and generating a refund transaction order for refunds according to the refund channel information.
2. The method of claim 1, further comprising determining whether a transaction balance of the original transaction number exceeds the current refund request amount in response to the original transaction number being consistent with the original transaction information.
3. The method of claim 2, wherein the transaction balance is a difference between a transaction amount of the original transaction number corresponding to the transaction and a cumulative sum of refunds that have occurred.
4. The method of claim 1, further comprising generating a transaction request parameter in response to the original transaction number matching the original transaction result.
5. The method of claim 1, further comprising generating a transaction request parameter from the original transaction information in response to the original transaction number not matching the original transaction result.
6. The method of claim 1, further comprising generating a refund inquiry in response to the refund transaction exceeding a predetermined time and periodically polling a status of the refund transaction to be confirmed.
7. The method of claim 1, wherein a GUID unique code is used for database operations to improve retrieval efficiency.
8. The method of claim 1, wherein the GUID unique code comprises a timestamp.
9. A cashier system, comprising:
business system, cashier desk and financial data processing system, financial system;
the business system comprises a business system foreground and a business system background, wherein the business system foreground provides various interfaces to interact with a user;
the business system foreground generates an order according to the operation of a user on the interface, wherein the order at least comprises business information and information to be paid, and the business information comprises: one or more of order number, service type, service content, user information, and service provider information, the information to be paid including: one or more of the amount to be paid and the currency information, and a business system foreground sends a transaction request to a cash register according to the order;
The service system background provides support for the service system foreground, records orders submitted by users, and extracts corresponding order data from the orders submitted by the users;
the cashier comprises a front end of the cashier, a payment platform interface and a cashier service system, wherein the front end of the cashier receives a transaction request from the front end of the business system, the transaction request comprises a part of business information and information to be paid, the front end of the cashier provides a payment page for a user or a clerk, a payment channel, a payment mode and payment amount information are confirmed according to the operation of the user, the payment platform interface is called to initiate a payment request to a third party payment platform, and a payment result and a transaction detail are received;
the payment platform interface is used for communicating with a third party payment platform, sending a payment request, and receiving a payment result and transaction details;
the cashier service system provides support for the front end of the cashier and the payment platform interface, the cashier service system provides transaction recording service, the cashier service system receives a transaction request from the front end of the cashier, adds new transactions in the established transaction pool, provides unique transaction numbers for each transaction, and records and updates the state of the transaction;
The front end of the cash register receives the transaction number from the cash register service system, and invokes a payment platform interface to send a payment request to a third party payment platform;
the financial data processing system comprises a business database, a clearing database and a financial credential system, wherein the business database receives business data from a business system background of the business system, and the business data comprises: the order data comprises business information or a part of the business information, the transaction data comprises a transaction number or a transaction number and a transaction detail or a part of the transaction number, the clearing database receives clearing data from a third party payment platform, the financial evidence system carries out clearing and checking by utilizing the business data of the business database and the clearing data of the clearing database, and a business evidence and a clearing evidence are manufactured according to requirements of the financial system;
the financial system includes a credential database that receives a clearing credential from a financial credential system of the financial data processing system;
a cash register service system for receiving a refund request from a business system; inquiring original transaction information according to the original transaction number in the refund request; and generating a transaction order in response to the transaction information in the refund request being consistent with the original transaction information; and
A paymate interface for generating a refund payment request from the transaction order; wherein generating the transaction order further comprises generating a GUID unique code and obtaining refund channel information; the cashier generates a transaction code of the refund transaction in the transaction pool, and stores the refund request information into the transaction pool; and generating a refund transaction order for refunds according to the refund channel information.
10. The system of claim 9, wherein the checkout counter comprises a checkout counter database.
11. The system of claim 9, wherein the checkout counter service system comprises:
the first cash register service module is used for interacting with the cash register database; and
and the second cash desk service module is used for receiving the payment request and the payment result and controlling the first cash desk service module to update the cash desk database.
12. The system of claim 10, the checkout counter database comprising:
a transaction pool table for recording the status of transactions;
a transaction request table for recording transaction requests; and
and the transaction result table is used for recording the transaction result corresponding to the transaction request.
13. The system of claim 12, the checkout counter database comprising: the transaction pool table comprises
A transaction pool master table for recording the status of transactions; and
a transaction pool sub-table for recording the status of transaction requests.
14. The system of claim 10, the checkout counter database comprising: and the refund request list is used for recording the refund requests existing in the database of the cash register.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810296195.7A CN108734457B (en) | 2018-04-04 | 2018-04-04 | Refund method under unified cashing system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810296195.7A CN108734457B (en) | 2018-04-04 | 2018-04-04 | Refund method under unified cashing system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108734457A CN108734457A (en) | 2018-11-02 |
| CN108734457B true CN108734457B (en) | 2023-11-07 |
Family
ID=63941225
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810296195.7A Active CN108734457B (en) | 2018-04-04 | 2018-04-04 | Refund method under unified cashing system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108734457B (en) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112334937B (en) * | 2019-06-04 | 2024-05-24 | 海付移通科技香港有限公司 | Refund method, transaction system, account system and storage medium |
| CN110415000A (en) * | 2019-07-26 | 2019-11-05 | 杭州首展科技有限公司 | A kind of method, apparatus, equipment and the storage medium of reimbursement processing |
| CN111080308A (en) * | 2019-12-25 | 2020-04-28 | 支付宝(杭州)信息技术有限公司 | Service information processing method and device and electronic equipment |
| CN111222866A (en) * | 2019-12-25 | 2020-06-02 | 北京多达通能源科技有限公司 | Refund processing method and device |
| CN112581277A (en) * | 2020-12-24 | 2021-03-30 | ***股份有限公司 | Data processing method and device |
| CN113723942A (en) * | 2021-07-29 | 2021-11-30 | 武汉轩迪科技有限公司 | Aggregated payment method, device, equipment and storage medium |
| CN113706140A (en) * | 2021-09-10 | 2021-11-26 | 百安居信息技术(上海)有限公司 | Cloud POS-based intelligent payment and refund method and electronic equipment |
| CN113592506B (en) * | 2021-09-27 | 2022-01-25 | 北京华益精点生物技术有限公司 | Repeated payment processing method and device, electronic equipment and storage medium |
| CN115375321A (en) * | 2022-09-01 | 2022-11-22 | 浙江康邻科技有限公司 | Refund device and method for card-free and secret-free refund of cross-acquiring mechanism |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105469297A (en) * | 2015-11-19 | 2016-04-06 | 中国建设银行股份有限公司 | Fund processing method for electronic commerce system and fund processing system for electronic commerce system |
| CN105512875A (en) * | 2015-11-26 | 2016-04-20 | 中国建设银行股份有限公司 | Refund data processing method applied to point-of-sale terminal and correlated systems |
| CN106355514A (en) * | 2016-08-31 | 2017-01-25 | 中国南方电网有限责任公司 | Management system and process for realizing electric charge collection through bank and power supply enterprise network on basis of account checking identification codes |
| CN106447455A (en) * | 2016-10-09 | 2017-02-22 | 广州唯品会信息科技有限公司 | Order pretreatment method and system based on e-commerce management system EBS |
| CN106960336A (en) * | 2017-03-14 | 2017-07-18 | 世纪禾光科技发展（北京）有限公司 | The method and system of cross-border electric business platform American Express reimbursement automation |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20020076406A (en) * | 2001-03-28 | 2002-10-11 | 국민신용카드 주식회사 | System and method for service using rf ic tour card, and storage media having program source thereof |
-
2018
- 2018-04-04 CN CN201810296195.7A patent/CN108734457B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105469297A (en) * | 2015-11-19 | 2016-04-06 | 中国建设银行股份有限公司 | Fund processing method for electronic commerce system and fund processing system for electronic commerce system |
| CN105512875A (en) * | 2015-11-26 | 2016-04-20 | 中国建设银行股份有限公司 | Refund data processing method applied to point-of-sale terminal and correlated systems |
| CN106355514A (en) * | 2016-08-31 | 2017-01-25 | 中国南方电网有限责任公司 | Management system and process for realizing electric charge collection through bank and power supply enterprise network on basis of account checking identification codes |
| CN106447455A (en) * | 2016-10-09 | 2017-02-22 | 广州唯品会信息科技有限公司 | Order pretreatment method and system based on e-commerce management system EBS |
| CN106960336A (en) * | 2017-03-14 | 2017-07-18 | 世纪禾光科技发展（北京）有限公司 | The method and system of cross-border electric business platform American Express reimbursement automation |
Non-Patent Citations (1)
| Title |
|---|
| 对医院财务管理***建设的探讨――以广州市第十二人民医院为例;招志涛;李步康;李燕;;现代医院(第11期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108734457A (en) | 2018-11-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108734457B (en) | Refund method under unified cashing system | |
| CN103413389B (en) | Based on bank account to non-banking account management and method of payment | |
| US20150081537A1 (en) | Apparatus, method, and computer program product for data cleansing and/or biller scrubbing | |
| US20100191622A1 (en) | Distributed Transaction layer | |
| JP2019512808A (en) | Method and system for recording point-to-point transaction processing | |
| CN108762727B (en) | Event-driven financial information processing method and system | |
| CN108830697A (en) | A kind of industry wealth integral system and method | |
| CN111027952A (en) | Unified payment system and method supporting intelligent energy service | |
| CN108765106A (en) | A kind of integrated financial affairs receipt generation method of industry wealth | |
| CN108711045A (en) | A kind of cash register system and cash method | |
| CN104657896A (en) | Data acquisition and sharing system for CMS (credit management system) credit information sharing management | |
| CN116664139B (en) | Settlement management system integrating multi-platform malls | |
| CN108694660A (en) | A kind of industry wealth integration account checking method | |
| KR100435854B1 (en) | System and method for managing a payment relation between the enterprises | |
| CN108765108A (en) | A kind of financial data system and method under industry wealth integration | |
| CN108765107A (en) | A kind of data save method under industry wealth integration | |
| KR102207653B1 (en) | System and method for deposit and withdrawal service using automated teller machine and computer program for the same | |
| KR100875246B1 (en) | Loan Information Provision System | |
| US20060029200A1 (en) | Method and system for improved travel transaction billing and reconciling | |
| CN116128668B (en) | Method, system and computer storage medium for matching bank certificate subjects | |
| KR20010000428A (en) | Apparatus and method for billing and payment using internet | |
| JP2002207952A (en) | System and method for suspense receipt management | |
| CN108764881A (en) | A kind of processing method and system of exception financial data | |
| US20130173328A1 (en) | Computerized system and method for managing injection of resources into a flow of multiple resource utilization events | |
| CN117934188A (en) | Financial ledger system and use method |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |