CN111833164A - Accounts payable checking system for hospital and supplier - Google Patents
Accounts payable checking system for hospital and supplier Download PDFInfo
- Publication number
- CN111833164A CN111833164A CN202010459607.1A CN202010459607A CN111833164A CN 111833164 A CN111833164 A CN 111833164A CN 202010459607 A CN202010459607 A CN 202010459607A CN 111833164 A CN111833164 A CN 111833164A
- Authority
- CN
- China
- Prior art keywords
- payment
- data
- contract
- result
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
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
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/12—Accounting
- G06Q40/125—Finance or payroll
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
-
- 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
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
- G06Q10/103—Workflow collaboration or project management
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- Human Resources & Organizations (AREA)
- General Business, Economics & Management (AREA)
- Health & Medical Sciences (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Bioethics (AREA)
- Entrepreneurship & Innovation (AREA)
- Economics (AREA)
- Marketing (AREA)
- General Engineering & Computer Science (AREA)
- General Health & Medical Sciences (AREA)
- Operations Research (AREA)
- Tourism & Hospitality (AREA)
- Databases & Information Systems (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Development Economics (AREA)
- Technology Law (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention provides an accounts payable checking system for hospitals and suppliers in the field of computers, which comprises: the account checking rule creating module is used for creating an account checking rule in the financial server; the data acquisition module is used for acquiring contract data and invoice data by the financial server through the contract server and sending the contract data and the invoice data to the cashier server; the payment result generation module is used for generating a payment result by the cashier server based on the contract data and the invoice data and sending the payment result to the financial server; the account checking result generating module is used for the financial server to check accounts based on the account checking rule, the payment result and the contract data to generate an account checking result; and the reconciliation result storage module is used for storing the reconciliation result into a pre-established database by the financial server and sending the reconciliation result to the financial terminal. The invention has the advantages that: the account checking efficiency and accuracy of accounts payable of the hospital and the supplier are greatly improved.
Description
Technical Field
The invention relates to the field of computers, in particular to an accounts payable reconciliation system for hospitals and suppliers.
Background
During the operation process of the hospital, the business account is inevitably generated with the purchasing unit or the unit receiving the labor. The payable is the money of the payable purchased goods in the hospital, which is formed by a whole set of business processing processes of invoice auditing, approving, paying, checking and account checking, and the strengthening and perfecting of the business process of the payable is an important content of payable management. The purchase of materials and labor are all medical services, and various materials, equipment and medicines have the characteristics of various varieties and quantities and frequent in and out, so that higher requirements are put forward for accounting.
Traditionally, hospital reconciliation has the following problems:
(1) many hospitals utilize the advantage of buyer's market, stipulate that just pay 4 months after goods supply company's medicine, chemical reagent send hospital's drug storage, this difficulty that alleviates the fund turnover of hospital greatly, but increased the mobile debt of hospital, increased the work load of accounts payable, and traditionally the account payable adopts artifical account checking, and hospital's management to accounts payable once relaxes, just produces various problems, and the concrete expression is in:
A. the goods are delivered to the drug warehouse, no formal invoice is made, and the goods are directly delivered out of the warehouse without being stored. Medicines are already sent to a medicine warehouse, due to various reasons, a supplier does not timely invoice correctly, so that a hospital cannot perform corresponding financial treatment, but due to business emergency, the medicines have to be sent out, so that the situation of negative stock on an account is caused. B. The formal invoice is issued, and due to various reasons, goods are not put in storage, so that the situation that the paid-in medicine is not put in storage is caused.
(2) Unlike the contracts specifically signed by various suppliers, the settlement time or settlement mode of accounts payable is unclear, the account checking workload of financial staff and suppliers is increased, and the settlement amount may be wrong.
Therefore, how to provide an account payable reconciliation system for hospitals and suppliers to improve the efficiency and accuracy of account payable reconciliation for hospitals and suppliers becomes a problem to be solved urgently.
Disclosure of Invention
The invention aims to provide an accounts payable reconciliation system for hospitals and suppliers, which can improve the efficiency and accuracy of accounts payable reconciliation of the hospitals and suppliers.
The invention is realized by the following steps: a accounts payable system for hospitals and suppliers comprises the following modules:
the account checking rule creating module is used for creating an account checking rule in the financial server;
the data acquisition module is used for acquiring contract data and invoice data through the contract server by the financial server, encrypting the contract data and the invoice data by using an encryption algorithm to generate first encrypted data, and then sending the first encrypted data to the receiving server;
the payment result generation module is used for decrypting the first encrypted data by the cashier server by using an encryption algorithm to obtain contract data and invoice data, generating a payment result based on the contract data and the invoice data, encrypting the payment result by using the encryption algorithm to generate second encrypted data, and then sending the second encrypted data to the financial server;
the reconciliation result generating module is used for decrypting the second encrypted data by using an encryption algorithm by the financial server to obtain a payment result, and performing reconciliation based on the reconciliation rule, the payment result and the contract data to generate a reconciliation result;
and the reconciliation result storage module is used for storing the reconciliation result into a pre-established database by the financial server and sending the reconciliation result to the financial terminal.
Further, in the reconciliation rule creation module, the reconciliation rule specifically includes: when the total payment amount corresponding to the contract code and the payment identification code is consistent, clearing is carried out; and if the two are inconsistent, the account is not cleared.
Further, the data acquisition module specifically includes:
a request sending unit, which is used for sending a data acquisition request to the contract server by the financial server;
the contract and invoice acquisition unit is used for acquiring contract data and invoice data through the contract terminal after the contract server receives the data acquisition request; the contract data comprises a contract code, a payment amount and a payment number;
the data sending unit is used for establishing a coding rule by the contract server, dividing contract data into full-amount contracts and installments based on the payment times, coding the payment amount of each full-amount contract and installments by using the coding rule to generate a payment identification code, encrypting the contract data and invoice data by using an encryption algorithm to generate first encrypted data, and then sending the first encrypted data to the financial server, and the financial server sends the first encrypted data to the receiving server.
Further, the encoding rule is specifically:
when the contract data is a full contract, the payment amount is encoded by using the date + YP to generate a payment identification code; when the contract data is in installments, the payment amount is encoded by using the date + YP + progress identification code to generate a payment identification code; wherein the date is a 6-bit string; the progress identification code is a 2-bit string that represents the number of payments due for an installment.
Further, in the data acquisition module, the invoice data includes a contract code, a payment amount, a supplier name, and a supplier tax number.
Further, in the payment result generation module, the generation of the payment result based on the contract data and the invoice data specifically includes:
generating a payment result by comparing the contract data and the invoice data with a payment record stored by a cashier server; the payment result is a payment or an unpaid payment.
Further, the reconciliation result generation module specifically includes:
the payment result judging unit is used for decrypting the second encrypted data by the financial server by using an encryption algorithm to obtain a payment result, judging whether the payment result is a payment clear or not, and entering the amount judging unit if the payment result is the payment clear; if not, ending the process;
the amount judgment unit is used for judging whether the payment amount in the contract data corresponding to the contract code is consistent with the total payment amount corresponding to the payment identification code or not based on the account checking rule, and if so, generating an account checking result; if not, the flow is ended.
Further, the reconciliation result comprises a contract code, a payment application date, a payment application amount and a payment amount.
Further, the encryption algorithm is a hash algorithm, a symmetric encryption algorithm or an asymmetric encryption algorithm.
Further, the contract terminal and the financial terminal are all mobile phones, tablet computers, notebooks or desktop computers.
The invention has the advantages that:
1. the account checking rule is established through the financial server, the contract data and the invoice data are acquired from the contract server and then sent to the cashier server, the cashier server generates a payment result based on the received contract data and the invoice data and sends the payment result to the financial server, the financial server then utilizes the account checking rule, the payment result and the contract data to perform account checking, namely, the whole account checking process is automatically performed through each server, the account checking efficiency is greatly improved compared with manual account checking, account checking is performed through the preset account checking rule and the payment result and the contract data, and the accuracy of account checking is greatly improved.
2. The interactive data of the financial server and the cashier server are encrypted through an encryption algorithm, so that the safety is greatly improved, and the risk that key data such as contract data, invoice data and payment results are stolen is reduced.
3. Through in will checking account result storage to the database to send for financial terminal, the staff of being convenient for checks account through financial terminal, and will check account result storage to the source of being convenient for later stage in the database.
4. The payment result is generated through the contract data and the invoice data, namely the contract data and the invoice data are respectively compared with the payment records stored by the cashier server for secondary verification, so that the consistency of the contract data and the invoice data is conveniently verified, and the accuracy of the payment result is greatly improved.
Drawings
The invention will be further described with reference to the following examples with reference to the accompanying drawings.
Fig. 1 is a schematic structural diagram of an accounts payable reconciliation system for hospitals and suppliers according to the present invention.
Fig. 2 is a hardware architecture diagram of the present invention.
Fig. 3 is a flowchart of a hospital and supplier accounts payable reconciliation system of the present invention.
Detailed Description
The technical scheme in the embodiment of the application has the following general idea: the account checking rule is established through the financial server, contract data and invoice data are obtained from the contract server and then are sent to the cashier server, the cashier server generates a payment result based on the received contract data and invoice data and sends the payment result to the financial server, and the financial server further utilizes the account checking rule, the payment result and the contract data to perform automatic account checking; the account checking is carried out by combining the payment result and the contract data through the preset account checking rule, and the accuracy of the account checking is improved.
Referring to fig. 1 to 3, a preferred embodiment of an accounts payable reconciliation system for hospitals and suppliers according to the present invention comprises the following modules:
the account checking rule creating module is used for creating an account checking rule in the financial server;
the data acquisition module is used for acquiring contract data and invoice data through the contract server by the financial server, encrypting the contract data and the invoice data by using an encryption algorithm to generate first encrypted data, and then sending the first encrypted data to the receiving server through an HTTP (hyper text transport protocol);
the payment result generation module is used for decrypting the first encrypted data by the cashier server by using an encryption algorithm to obtain contract data and invoice data, generating a payment result based on the contract data and the invoice data, encrypting the payment result by using the encryption algorithm to generate second encrypted data, and then sending the second encrypted data to the financial server;
the reconciliation result generating module is used for decrypting the second encrypted data by using an encryption algorithm by the financial server to obtain a payment result, and performing reconciliation based on the reconciliation rule, the payment result and the contract data to generate a reconciliation result;
the account checking result storage module is used for storing the account checking result into a pre-established database by the financial server and sending the account checking result to the financial terminal; through in will checking account result storage to the database to send for financial terminal, the staff of being convenient for checks account through financial terminal, and will check account result storage to the source of being convenient for later stage in the database.
In the reconciliation rule creating module, the reconciliation rule specifically comprises: when the total payment amount corresponding to the contract code and the payment identification code is consistent, clearing is carried out; and if the two are inconsistent, the account is not cleared.
The data acquisition module specifically comprises:
a request sending unit, which is used for sending a data acquisition request to the contract server by the financial server;
the contract and invoice acquisition unit is used for acquiring contract data and invoice data through the contract terminal after the contract server receives the data acquisition request; the contract data comprises a contract code, a payment amount and a payment number;
the data sending unit is used for establishing a coding rule by the contract server, dividing contract data into full-amount contracts and installments based on the payment times, coding the payment amount of each full-amount contract and installments by using the coding rule to generate a payment identification code, encrypting the contract data and invoice data by using an encryption algorithm to generate first encrypted data, and then sending the first encrypted data to the financial server, and the financial server sends the first encrypted data to the receiving server.
The encoding rule is specifically as follows:
when the contract data is a full contract, the payment amount is encoded by using the date + YP to generate a payment identification code; when the contract data is in installments, the payment amount is encoded by using the date + YP + progress identification code to generate a payment identification code; wherein the date is a 6-bit string; the progress identification code is a 2-bit string that represents the number of payments due for an installment.
For example, in the full-payment contract, the payment amount of a certain medicine is 19 years, 3 months and 10 days, and the payment identification code is 190310 YP; in the installment contract, the payment amount of a certain medicine for the second time on 3 months and 10 days in 19 years is 190310YP 02; YP denotes an abbreviation of drug; limiting the number of coded bits is used to prevent errors.
In the data acquisition module, the invoice data includes a contract code, a payment amount, a supplier name and a supplier tax number.
In the payment result generation module, the generation of the payment result based on the contract data and the invoice data specifically includes:
generating a payment result by comparing the contract data and the invoice data with a payment record stored by a cashier server; the payment result is a payment or an unpaid payment.
The reconciliation result generation module specifically comprises:
the payment result judging unit is used for decrypting the second encrypted data by the financial server by using an encryption algorithm to obtain a payment result, judging whether the payment result is a payment clear or not, and entering the amount judging unit if the payment result is the payment clear; if not, ending the process;
the amount judgment unit is used for judging whether the payment amount in the contract data corresponding to the contract code is consistent with the total payment amount corresponding to the payment identification code or not based on the account checking rule, and if so, generating an account checking result; if not, the flow is ended.
When the contract is a full contract, judging whether the payment amount in the contract data corresponding to the contract code is consistent with the payment amount corresponding to the payment identification code (date + YP); when the contract is an installment contract, whether the payment amount in the contract data corresponding to the contract code is consistent with the total payment amount corresponding to the payment identification code is judged, that is, all payment amounts with the same date + YP, such as the total 190310YP01, 190310YP02 and 190310YP03, are added, and whether the total payment amount is consistent with the payment amount in the contract data is judged.
The account checking result comprises a contract code, a payment applying date, a payment applying amount and a payment amount.
The encryption algorithm is a Hash algorithm, a symmetric encryption algorithm or an asymmetric encryption algorithm; the interactive data of the financial server and the cashier server are encrypted through an encryption algorithm, so that the safety is greatly improved, and the risk that key data such as contract data, invoice data and payment results are stolen is reduced.
And the contract terminal and the financial terminal are all mobile phones, tablet computers, notebooks or desktop computers.
In summary, the invention has the advantages that:
1. the account checking rule is established through the financial server, the contract data and the invoice data are acquired from the contract server and then sent to the cashier server, the cashier server generates a payment result based on the received contract data and the invoice data and sends the payment result to the financial server, the financial server then utilizes the account checking rule, the payment result and the contract data to perform account checking, namely, the whole account checking process is automatically performed through each server, the account checking efficiency is greatly improved compared with manual account checking, account checking is performed through the preset account checking rule and the payment result and the contract data, and the accuracy of account checking is greatly improved.
2. The interactive data of the financial server and the cashier server are encrypted through an encryption algorithm, so that the safety is greatly improved, and the risk that key data such as contract data, invoice data and payment results are stolen is reduced.
3. Through in will checking account result storage to the database to send for financial terminal, the staff of being convenient for checks account through financial terminal, and will check account result storage to the source of being convenient for later stage in the database.
4. The payment result is generated through the contract data and the invoice data, namely the contract data and the invoice data are respectively compared with the payment records stored by the cashier server for secondary verification, so that the consistency of the contract data and the invoice data is conveniently verified, and the accuracy of the payment result is greatly improved.
Although specific embodiments of the invention have been described above, it will be understood by those skilled in the art that the specific embodiments described are illustrative only and are not limiting upon the scope of the invention, and that equivalent modifications and variations can be made by those skilled in the art without departing from the spirit of the invention, which is to be limited only by the appended claims.
Claims (10)
1. The utility model provides a hospital and supplier accounts payable money reconciliation system which characterized in that: the system comprises the following modules:
the account checking rule creating module is used for creating an account checking rule in the financial server;
the data acquisition module is used for acquiring contract data and invoice data through the contract server by the financial server, encrypting the contract data and the invoice data by using an encryption algorithm to generate first encrypted data, and then sending the first encrypted data to the receiving server;
the payment result generation module is used for decrypting the first encrypted data by the cashier server by using an encryption algorithm to obtain contract data and invoice data, generating a payment result based on the contract data and the invoice data, encrypting the payment result by using the encryption algorithm to generate second encrypted data, and then sending the second encrypted data to the financial server;
the reconciliation result generating module is used for decrypting the second encrypted data by using an encryption algorithm by the financial server to obtain a payment result, and performing reconciliation based on the reconciliation rule, the payment result and the contract data to generate a reconciliation result;
and the reconciliation result storage module is used for storing the reconciliation result into a pre-established database by the financial server and sending the reconciliation result to the financial terminal.
2. The hospital and supplier accounts payable reconciliation system of claim 1 wherein: in the reconciliation rule creating module, the reconciliation rule specifically comprises: when the total payment amount corresponding to the contract code and the payment identification code is consistent, clearing is carried out; and if the two are inconsistent, the account is not cleared.
3. The hospital and supplier accounts payable reconciliation system of claim 1 wherein: the data acquisition module specifically comprises:
a request sending unit, which is used for sending a data acquisition request to the contract server by the financial server;
the contract and invoice acquisition unit is used for acquiring contract data and invoice data through the contract terminal after the contract server receives the data acquisition request; the contract data comprises a contract code, a payment amount and a payment number;
the data sending unit is used for establishing a coding rule by the contract server, dividing contract data into full-amount contracts and installments based on the payment times, coding the payment amount of each full-amount contract and installments by using the coding rule to generate a payment identification code, encrypting the contract data and invoice data by using an encryption algorithm to generate first encrypted data, and then sending the first encrypted data to the financial server, and the financial server sends the first encrypted data to the receiving server.
4. The hospital and supplier accounts payable reconciliation system of claim 3 wherein: the encoding rule is specifically as follows:
when the contract data is a full contract, the payment amount is encoded by using the date + YP to generate a payment identification code; when the contract data is in installments, the payment amount is encoded by using the date + YP + progress identification code to generate a payment identification code; wherein the date is a 6-bit string; the progress identification code is a 2-bit string that represents the number of payments due for an installment.
5. The hospital and supplier accounts payable reconciliation system of claim 1 wherein: in the data acquisition module, the invoice data includes a contract code, a payment amount, a supplier name and a supplier tax number.
6. The hospital and supplier accounts payable reconciliation system of claim 1 wherein: in the payment result generation module, the generation of the payment result based on the contract data and the invoice data specifically includes:
generating a payment result by comparing the contract data and the invoice data with a payment record stored by a cashier server; the payment result is a payment or an unpaid payment.
7. The hospital and supplier accounts payable reconciliation system of claim 3 wherein: the reconciliation result generation module specifically comprises:
the payment result judging unit is used for decrypting the second encrypted data by the financial server by using an encryption algorithm to obtain a payment result, judging whether the payment result is a payment clear or not, and entering the amount judging unit if the payment result is the payment clear; if not, ending the process;
the amount judgment unit is used for judging whether the payment amount in the contract data corresponding to the contract code is consistent with the total payment amount corresponding to the payment identification code or not based on the account checking rule, and if so, generating an account checking result; if not, the flow is ended.
8. The hospital and supplier accounts payable reconciliation system of claim 7 wherein: the account checking result comprises a contract code, a payment applying date, a payment applying amount and a payment amount.
9. The hospital and supplier accounts payable reconciliation system of claim 1 wherein: the encryption algorithm is a hash algorithm, a symmetric encryption algorithm or an asymmetric encryption algorithm.
10. The hospital and supplier accounts payable reconciliation system of claim 1 wherein: and the contract terminal and the financial terminal are all mobile phones, tablet computers, notebooks or desktop computers.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010459607.1A CN111833164A (en) | 2020-05-27 | 2020-05-27 | Accounts payable checking system for hospital and supplier |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010459607.1A CN111833164A (en) | 2020-05-27 | 2020-05-27 | Accounts payable checking system for hospital and supplier |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111833164A true CN111833164A (en) | 2020-10-27 |
Family
ID=72914023
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010459607.1A Pending CN111833164A (en) | 2020-05-27 | 2020-05-27 | Accounts payable checking system for hospital and supplier |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111833164A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113539450A (en) * | 2021-04-27 | 2021-10-22 | 安徽省立医院(中国科学技术大学附属第一医院) | Method for purchasing and paying medicine in hospital |
| CN113689273A (en) * | 2021-07-22 | 2021-11-23 | 北京健康之家科技有限公司 | Service data processing method and system |
| CN114707993A (en) * | 2022-04-02 | 2022-07-05 | 国网江苏省电力有限公司连云港供电分公司 | Contract studying and judging method, system and network side server |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20100106653A1 (en) * | 2008-10-24 | 2010-04-29 | Combinenet, Inc. | System and Method for Contract Execution Against Expressive Contracts |
| CN107798109A (en) * | 2017-11-01 | 2018-03-13 | 深圳市牛鼎丰科技有限公司 | Method, apparatus, computer equipment and the storage medium of reconciliation clearance |
| CN111144995A (en) * | 2019-12-27 | 2020-05-12 | 金螳螂家装电子商务（苏州）有限公司 | Shop purchase reconciliation management system and method based on home decoration industry |
| CN111192669A (en) * | 2019-12-23 | 2020-05-22 | 福建亿能达信息技术股份有限公司 | Automatic account checking method for hospital and supplier prepayment accounts under medical community |
-
2020
- 2020-05-27 CN CN202010459607.1A patent/CN111833164A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20100106653A1 (en) * | 2008-10-24 | 2010-04-29 | Combinenet, Inc. | System and Method for Contract Execution Against Expressive Contracts |
| CN107798109A (en) * | 2017-11-01 | 2018-03-13 | 深圳市牛鼎丰科技有限公司 | Method, apparatus, computer equipment and the storage medium of reconciliation clearance |
| CN111192669A (en) * | 2019-12-23 | 2020-05-22 | 福建亿能达信息技术股份有限公司 | Automatic account checking method for hospital and supplier prepayment accounts under medical community |
| CN111144995A (en) * | 2019-12-27 | 2020-05-12 | 金螳螂家装电子商务（苏州）有限公司 | Shop purchase reconciliation management system and method based on home decoration industry |
Non-Patent Citations (1)
| Title |
|---|
| 陈政 等编著: "《挖掘第三利润 施工企业物资管理与核算的12道关键环节》", 31 January 2016, 中国市场出版社 * |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113539450A (en) * | 2021-04-27 | 2021-10-22 | 安徽省立医院(中国科学技术大学附属第一医院) | Method for purchasing and paying medicine in hospital |
| CN113689273A (en) * | 2021-07-22 | 2021-11-23 | 北京健康之家科技有限公司 | Service data processing method and system |
| CN114707993A (en) * | 2022-04-02 | 2022-07-05 | 国网江苏省电力有限公司连云港供电分公司 | Contract studying and judging method, system and network side server |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110263024B (en) | Data processing method, terminal device and computer storage medium | |
| US20240242210A1 (en) | Systems and methods for message conversion and validation | |
| US20240338686A1 (en) | Method and system for transaction processing with complete cryptographic auditability | |
| CN111640014B (en) | Block chain technology-based account-receivable, credit and right-of-use financing system and method | |
| US11605076B2 (en) | Reconciliation of indirectly executed exchanges of data using permissioned distributed ledgers | |
| CN111833164A (en) | Accounts payable checking system for hospital and supplier | |
| US11727484B2 (en) | Methods and apparatus for mortgage loan securitization based upon mortgage servicing stored on blockchain | |
| US6901387B2 (en) | Electronic purchasing method and apparatus for performing the same | |
| AU2007242060B2 (en) | Automated budget management, multiple payment, and payment authority management | |
| US20160180303A1 (en) | System, method, and computer program product for processing payments | |
| US11270313B2 (en) | Real-time resource account verification processing system | |
| US20150213444A1 (en) | Systems and methods for improving data processing and management | |
| US20190318333A1 (en) | Real-time network processing nucleus | |
| WO2024119789A1 (en) | Fund releasing method and apparatus, and computer device and readable storage medium | |
| CN115526617A (en) | Block chain-based digital RMB payment method, system, medium and equipment | |
| CN111209449A (en) | Automatic account checking method for accounts payable of hospital and supplier under medical community | |
| US8527376B1 (en) | Income itemization | |
| US20200302407A1 (en) | Real-time resource split distribution network | |
| CN110766403A (en) | Data processing device and method based on block chain and storage medium | |
| CN111178826A (en) | Consumption financial risk management method based on block chain and cloud platform | |
| CN110163732A (en) | A kind of processing method and processing system of accounting statement | |
| CN111932255B (en) | Method and device for realizing transaction reconciliation based on encrypted currency | |
| Dener | Treasury Single Account Rapid Assessment Toolkit | |
| CN113689215A (en) | Tape quantity purchase settlement method, system, computer equipment and storage medium | |
| AU2019229419A1 (en) | Automated budget management, multiple payment, and payment authority management |
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 | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20201027 |