A method and system for tracing back a medical insurance personal account gold withdrawal failure

Abstract

The present application belongs to the technical field of data processing, and proposes a medical insurance personal account gold revocation failure flow tracing method and system. When the operation of refunding the medical insurance personal account gold to the medical insurance account fails, first mark the original card gold revocation flow as a refund failure state, then create an equivalent cash refund flow as compensation, change the payment method to cash, and set the medical insurance participation identifier to not participate in medical insurance reimbursement accounting. The original card gold revocation flow and the new cash refund flow are both pointed to the same original card gold payment flow through the association identifier field, forming a triangular association structure, which supports tracing from any one flow to the complete refund change history. The present application eliminates the uncertain state in the refund process and provides complete reconciliation and audit tracing.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, and in particular relates to a method and system for tracing transaction records when the cancellation of medical insurance personal account funds fails. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] Refunds of medical insurance personal accounts rely on the medical insurance center system to complete the write-back operation. When the medical insurance center system malfunctions, experiences network interruption, or has an abnormal account status, the refund operation may fail. In this case, the pooled fund portion may have been successfully refunded, but the personal account portion cannot be refunded to the medical insurance personal account. After the personal account refund fails, the status of the original personal account cancellation record is in an uncertain state, resulting in an inconsistent state of partial success in the refund process, affecting the calculation and settlement loop of the overall refund status. Summary of the Invention

[0004] To overcome the shortcomings of the prior art, this invention provides a method and system for tracing transaction records when the cancellation of medical insurance personal account funds fails. When the operation of refunding medical insurance personal account funds to the medical insurance account fails, an equivalent cash refund transaction record is created, while retaining the dual association between the original failed transaction record and the compensation transaction record. This eliminates the uncertain state in the refund process and achieves complete reconciliation and audit traceability.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a method for tracing transaction records when the cancellation of medical insurance personal account funds fails, comprising: Check whether the process of transferring funds from the individual medical insurance account to the medical insurance account failed, and whether the portion from the medical insurance pooled fund was successfully withdrawn; If the refund of medical insurance personal account funds to medical insurance account fails, but the medical insurance pooled fund is successfully cancelled, the original card fund payment transaction with medical insurance personal account fund type will be screened out from all related transaction data related to the original payment through associated query, and the corresponding original card fund cancellation transaction will be obtained based on the identification information of the original card fund payment transaction. Update the status information of the original card cancellation transaction to "refund failed" and update the payment type information of the original card cancellation transaction to "refund payment type", while recording the reason for failure. Based on the refund amount of the original card cancellation transaction, a new cash refund transaction is created; wherein, the refund amount of the new cash refund transaction inherits the refund amount of the original card cancellation transaction, the payment method is set to cash, the medical insurance participation identifier is set to not participate in medical insurance reimbursement calculation, and the status information is set to refund successful. Both the original card cancellation transaction and the new cash refund transaction are associated with the same original card payment transaction through their respective association identifiers.

[0006] Secondly, the present invention provides a method for tracing transaction records when the cancellation of medical insurance personal account funds fails, including: The detection module is configured to detect whether the operation of refunding funds from the individual medical insurance account to the medical insurance account has failed, and whether the portion of the medical insurance pooled fund has been successfully withdrawn. The query module is configured to: if the operation of refunding medical insurance personal account funds to medical insurance account fails, and the medical insurance pooled fund part is successfully cancelled, then through the associated query, filter out the original card fund payment flow with the payment method of medical insurance personal account funds from all related flow flow related to the original payment, and query the corresponding original card fund cancellation flow based on the identification information of the original card fund payment flow. The update module is configured to: update the status information of the original card cancellation transaction to a refund failure status, update the payment type information of the original card cancellation transaction to a refund payment type, and record the failure reason information; The creation module is configured to: create a new cash refund transaction based on the refund amount of the original card cancellation transaction; wherein, the refund amount of the new cash refund transaction inherits the refund amount of the original card cancellation transaction, the payment method is set to cash type, the medical insurance participation identifier is set to not participate in medical insurance reimbursement calculation, and the status information is set to refund successful status; The association module is configured to associate both the original card payment cancellation record and the new cash refund record with the same original card payment record using their respective association identifiers. Thirdly, the present invention provides an electronic device including a memory and a processor, and computer instructions stored in the memory and running on the processor, wherein the computer instructions, when executed by the processor, perform the method described in the first aspect.

[0007] Fourthly, the present invention provides a computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the method described in the first aspect.

[0008] Fifthly, the present invention provides a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect.

[0009] The above one or more technical solutions have the following beneficial effects: In this invention, when the refund from a personal medical insurance account to a medical insurance account fails, the original card payment cancellation record is first marked as a refund failure. Then, an equivalent cash refund record is created as compensation, with the payment method changed to cash, and the medical insurance participation flag set to not participate in medical insurance reimbursement calculation. The original card payment cancellation record and the new cash refund record both point to the same original card payment record through an association identifier field, forming a triangular association structure. This allows for tracing the complete refund change history from any record. This invention eliminates uncertainties in the refund process and provides complete reconciliation and audit traceability functions.

[0010] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0011] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0012] Figure 1 This is a schematic diagram of medical insurance payment records in Embodiment 1 of the present invention; Figure 2 This is a complete flowchart of the manual intervention path in Embodiment 1 of the present invention; Figure 3 This is a flowchart of the automatic write-back path in Embodiment 1 of the present invention; Figure 4 This is a schematic diagram of the dual-flow triangular association query in Embodiment 1 of the present invention. Detailed Implementation

[0013] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0014] It should be noted that the terminology used herein is for the purpose of describing particular implementations only and is not intended to limit the exemplary implementations of the present invention.

[0015] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0016] Example 1 This embodiment discloses a method for tracing transaction records when the cancellation of medical insurance personal account funds fails, including: Check whether the process of transferring funds from the individual medical insurance account to the medical insurance account failed, and whether the portion from the medical insurance pooled fund was successfully withdrawn; If the refund of medical insurance personal account funds to medical insurance account fails, but the medical insurance pooled fund is successfully cancelled, the original card fund payment transaction with medical insurance personal account fund type will be screened out from all related transaction data related to the original payment through associated query, and the corresponding original card fund cancellation transaction will be obtained based on the identification information of the original card fund payment transaction. Update the status information of the original card cancellation statement to "refund failed" and update the payment type information of the original card cancellation statement to "refund payment type", while recording the reason for failure. Based on the refund amount of the original card cancellation transaction, create a new cash refund transaction; the refund amount of the new cash refund transaction inherits the refund amount of the original card cancellation transaction, the payment method is set to cash, the medical insurance participation identifier is set to not participate in medical insurance reimbursement calculation, and the status information is set to refund successful. Both the original card cancellation transaction and the new cash refund transaction are linked to the same original card payment transaction through their respective association identifiers.

[0017] As one implementation method, through association query, the original card payment transaction with the payment method of medical insurance personal account fund is filtered out from all related transaction records related to the original payment. Based on the identification information of the original card payment transaction, the corresponding original card cancellation transaction is obtained. Specifically, the original payment transaction is queried using the primary key identifier as the query condition, and all related transaction records are queried. Records with the payment method identifier of medical insurance personal account fund are filtered out from all related transaction records to obtain the original card payment transaction. Using the primary key identifier of the original card payment transaction as the query condition, the cancellation transaction record associated with the original card payment transaction is queried. A negative transaction record of medical insurance card fund and cash will be found. The medical insurance card fund transaction is invalidated and the original card cancellation transaction is obtained.

[0018] As one implementation method, while updating the status information of the original card cancellation transaction to a refund failure status, it also includes synchronously updating the status information of other transactions associated with the original card cancellation transaction.

[0019] As one implementation method, the associated identifier field value of the original card payment cancellation record is equal to the primary key identifier of the original card payment record, and the associated identifier field value of the new cash refund record is equal to the primary key identifier of the same original card payment record; using the primary key identifier of the original card payment record as the query condition, the original card payment cancellation record with a status of refund failure and the new cash refund record with a status of refund success are retrieved simultaneously.

[0020] As one implementation method, it also includes the mandatory cancellation process for the pooled fund portion, specifically: canceling the medical insurance network settlement data and marking the medical insurance network settlement record as canceled; writing the cancellation result back to the settlement service through the payment callback notification service; and updating the status of the original pooled payment transaction to canceled.

[0021] As one implementation method, the following pre-detection conditions are also included: detecting whether the modification type is a cancellation type; detecting whether the transaction type requires this settlement scenario; detecting whether the transaction entity identifiers of the original payment record and the cancellation record are different, in order to confirm whether the current operation belongs to the cancellation operation of the refund stage; and detecting whether the payment method of the original payment record is the medical insurance pooled payment type.

[0022] In this embodiment, creating a new cash refund transaction record also includes the following field settings: the payment platform code is set to the cash payment platform code "CASH"; the payment method identifier is set to the cash payment method identifier CASH_PAY; the merchant identifier is set to the merchant identifier in the cash merchant configuration; the medical insurance review status is set to 0, indicating no medical insurance review; the transaction number is set to the string value of the newly generated transaction record primary key identifier; and the refund reason information is set to "medical insurance card cash to cash refund".

[0023] The following is combined Figure 1 This embodiment provides a detailed explanation of a method for tracing transaction records when the cancellation of medical insurance personal account funds fails: Step S1: Cancel the failure detection.

[0024] The system checks whether the refund process for funds in the individual medical insurance account has failed. This scenario is identified by modifying a specific status code (INSURANCE_CARD_REVOKED_FAIL) in the status enumeration. This status code means "The pooled fund withdrawal was successful, but the refund of funds from the medical insurance card failed and needs to be automatically converted to a cash refund."

[0025] The detection conditions include: the modification type is a reversal type (REVOKE); the modification status is card cancellation failure (INSURANCE_CARD_REVOKED_FAIL); the transaction type is not bedside settlement; the transaction entity IDs of the original payment transaction and the reversal transaction are different (confirming that it belongs to "reversal in refund" rather than "reversal in payment").

[0026] Step S2: The overall planning part is forcibly revoked first.

[0027] Before implementing the cardholder compensation, the mandatory cancellation of the pooled fund portion must be completed, including: Reversing medical insurance network settlement data: Marking medical insurance network settlement records as reversed; Revocation Writeback Notification: The revocation result will be written back to the settlement service via the payment callback notification service; Update the status of the original pooled payment transaction: Update the status of the pooled payment transaction to "Cancelled". This step ensures that the pooled fund portion has been successfully refunded, providing a prerequisite for subsequent card payment compensation.

[0028] Step S3: Card-related flow location.

[0029] Locate the original medical insurance card payment records and their cancellation records through related queries: Using the paymentId of the original payment record as the query condition, query all related records using the findAllRelationRecord() method; Filter records in the related records where payTypeId is the medical insurance card payment type (MEDICAL_INSURANCE_CARD_PAY) to obtain the original card payment records; Use the paymentId of the original card payment records as the query condition to query its cancellation records again.

[0030] Step S4: The original card failed to cancel the transaction mark.

[0031] Update the status of the original medical insurance card cancellation / refund transaction record to "refund failed": update the status field to FAILED (status code 5) to indicate that the refund failed; update the paymentType field to REFUND_PAY (type code 3) to clearly identify it as a refund operation; set the errorShortMsg field to "manual intervention modified to refund failed" to record the reason for failure; call the syncStatus() method to synchronize the status of the associated transaction record.

[0032] Step S5: Create a cash compensation refund transaction record.

[0033] Create a new cash refund transaction with the same amount as the original card refund cancellation transaction: Reset the fields based on the original card refund cancellation transaction entity; generate a new transaction primary key `payingId`; set `status` to `PAID` (status code 3) to mark it as a successful refund; set `payingType` to `REFUND_PAY` (type code 3); set `payTypeCode` to "CASH"; set `payTypeId` to the encoded value of `CASH_PAY`; set `merchantId` to the merchant ID in the cash merchant configuration; set `joinMedInsurance` to 0 to indicate that this transaction will not participate in medical insurance reimbursement calculation; set `medicareStatus` to 0; set `tradeNo` to the string value of the new `payingId`; inherit `receiveAmount` from the original card refund cancellation transaction (a negative value); keep `relationPayingId` as the original card refund cancellation transaction's `relationPayingId` value, pointing to the `payingId` of the original card refund transaction, establishing a connection with the original payment transaction; INSERT the new transaction record into the payment record table.

[0034] Step S6: Establish the dual-flow association.

[0035] like Figure 4 As shown, through steps S4 and S5 above, a dual-transaction relationship structure is automatically formed: the `relationPayingId` field of both the original card payment cancellation transaction marked `FAILED` and the new cash refund transaction marked `PAID` points to the same `payingId` of the original card payment transaction, forming a triangular relationship structure of "one original payment transaction → one failed cancellation transaction + one successful cash refund transaction". All related transactions can be queried using the `findAllRelationRecord()` method to achieve complete reconciliation and traceability.

[0036] In this embodiment, as Figure 3 As shown, when the medical insurance core system writes back the refund result, it detects that the refund of personal account funds has failed and executes steps S4 and S5. The automatic trigger path is only applicable to inpatient settlement scenarios, and the payment type of the cash refund transaction created is transfer payment rather than refund payment.

[0037] The trigger condition for this embodiment is the failure of the operation to refund funds from the individual medical insurance account to the medical insurance account, rather than a general payment method switch.

[0038] In this embodiment, a "failure flag" operation (status=FAILED,payingType=REFUND_PAY) is performed on the original card refund cancellation transaction, instead of simply deleting or ignoring the failed transaction. The failed transaction is retained in the system, recording the complete history of "card refund attempted but failed".

[0039] In this embodiment, the newly created cash refund transaction amount is exactly the same as the original card cancellation transaction amount (inheriting the negative value of receiveAmount), rather than recalculating the refund amount. This ensures the accuracy and consistency of the refund amount.

[0040] In this embodiment, the original card refund cancellation record and the new cash refund record are linked to the same original card refund record through the relationPayingId field, forming a triangular association structure. This structure supports querying all refund attempts (including failed card refunds and successful cash refunds) for a given original payment record; it explicitly identifies "cash refund records as substitutes for card refunds" during reconciliation; and it allows for tracing the complete refund change history during auditing.

[0041] In this embodiment, the new cash refund transaction record sets joinMedInsurance to 0 and medicareStatus to 0, explicitly indicating that this transaction record will not participate in medical insurance reimbursement calculation. This is because cash refunds do not circulate within the medical insurance system and should not be included in medical insurance settlement data.

[0042] In this embodiment, the mandatory cancellation of the pooled fund portion is completed first to ensure that the pooled fund has been successfully refunded before the cash compensation for the card portion is executed. This sequential constraint avoids the inconsistency of "pooled fund not being refunded but card compensation already being made".

[0043] The following example, using an outpatient and inpatient scenario, describes the complete process of triggering the transfer of prepaid card funds to cash compensation through manual approval. Figure 2 As shown, the prerequisites are: a medical insurance payment includes both pooled fund payment records and card payment records; the pooled portion has been withdrawn and refunded; the card portion refund operation failed (the medical insurance center system could not complete the account fund write-back); the manual intervention approval platform displays the modification option "Pooled fund withdrawal successful, card refund failed".

[0044] Step S1-1: Build parameters.

[0045] The manual intervention approval platform receives approval operations and constructs the extendMap parameter, which includes cashMerchantId (cash merchant ID, obtained by querying the CASH type merchant configuration through merchantService), newPayPlatform (payment platform version identifier), outInFlag (outpatient / inpatient identifier), and patAccountId (patient account ID).

[0046] Step S1-2: Modify type distribution.

[0047] Select the OrderRevokeModifyServiceImpl implementation class based on ModifyTypeEnum=REVOKE.

[0048] The corresponding implementation is found by using the ConcurrentHashMap dispatch mechanism of AbstractModifyFactory and the return value of the modifyType() method as a strategy identifier.

[0049] Step S1-3: Locking and status verification.

[0050] Acquire a distributed lock using RedisLock.tryLock (maximum wait time 2 seconds, lock for 300 seconds), and verify the validity of the state of payRecord and revokeRecord.

[0051] Step S2: Coordinate and forcibly cancel the actions.

[0052] Execute the forceRevoke method: reverse the medical insurance network settlement data (mark NetworkSettleMainDTO as reversed); Revocation of write-back notification: The payment service coordination has been revoked via PayNotifyServiceManager; the status of the coordinated payment transaction is updated (status → REVOKED).

[0053] Step S3: Card-related flow location.

[0054] Query all related transaction records using the original payment transaction record's payingId (SELECT * FROM finance.trading_pay_record WHERE relation_paying_id = #{payingId} AND invalid_flag = '0'), filter for records with payTypeId as MEDICAL_INSURANCE_CARD_PAY to obtain the original card payment transaction record P3, and then query its cancelled transaction record P4 using the payingId of P3.

[0055] Step S4: The original card failed to cancel the transaction mark.

[0056] Update the original card cancellation transaction P4: status→FAILED(5), paymentType→REFUND_PAY(3), errorShortMsg→"Manual intervention changed to refund failure"; call syncStatus(P4) to synchronize the associated transaction status.

[0057] Step S5: Create a cash compensation refund transaction record.

[0058] After resetting the fields of the original card payment cancellation transaction P4 entity, modify the following key fields: payingId → newly generated distributed ID (P5); status → PAID (3); payingType → REFUND_PAY (3); payTypeCode → "CASH"; payTypeId → CASH_PAY encoded value; merchantId → cash merchant ID; joinMedInsurance → 0; medicareStatus → 0; tradeNo → P5 string value; receiveAmount → inherit the negative amount from P4; relationPayingId → keep P3 (payingId of the original card payment transaction); errorShortMsg → "manual intervention for medical insurance card payment to cash refund"; INSERT to the finance.trading_pay_record table.

[0059] Step S6: Establish triangular relationships.

[0060] P4.relationPayingId=P3, P5.relationPayingId=P3. By using findAllRelationRecord(P3), both P4 and P5 can be found simultaneously, forming a triangular relationship structure.

[0061] The following describes the process of automatically triggering the transfer of funds from the medical insurance card to cash compensation via a write-back process through the core medical insurance system, using a hospitalization scenario as an example. Figure 3 As shown, the preconditions are: inpatient settlement scenario; the medical insurance core system writes back the refund result, and the card refund result is failed.

[0062] Steps SA1-SA3: Receive medical insurance core write-back data, detect card refund failure, and verify that the transaction type is inpatient settlement.

[0063] Step SA4: Update the original card cancellation transaction record to FAILED status (same as step S4 above).

[0064] Step SA5: After creating the basic refund record using the AbstractBackWriteService.getRevokeRecord() template method, overwrite the cash refund configuration: payingType → TRANSFER_REFUND_PAY(4) (transfer to refund operation, not refund operation); payTypeId → CASH_PAY encoding value; payTypeCode → "CASH"; joinMedInsurance → 0; status → PAID(3); merchantId → cash merchant ID; relationPayingId → the payingId of the original card payment transaction; body → "Automatic cash transfer after medical insurance card refund failure"; errorShortMsg → "Automatic cash refund after medical insurance card refund failure"; INSERT to the finance.trading_pay_record table.

[0065] Step SA6: Establish the triangular relationship structure (same as step S6 above).

[0066] The access control mechanism for the card-to-cash transfer operation in this embodiment will be described in detail below to prevent accidental operation: Access condition 1: The modification type must be a cancellation type (ModifyTypeEnum=REVOKE). This operation is not allowed to be triggered through the payment modification or refund modification entry.

[0067] Eligibility condition 2: The status must be changed to "Card Revocation Failed" (ModifyStatusEnum=INSURANCE_CARD_REVOKED_FAIL, status code "8"). This status code is specifically used to identify the scenario where "the overall planning was successfully revoked but the card refund failed".

[0068] Admission condition 3: The transaction type is not allowed to be bedside settlement (rejected when TradeTypeEnum.isInBedSettle returns true), because the real-time requirements of bedside settlement scenarios do not apply to this asynchronous compensation mechanism.

[0069] Access condition 4: The payTypeId of the original payment transaction must be a medical insurance payment type (MEDICAL_INSURANCE_PAY) to ensure that the object of the operation is a medical insurance payment transaction.

[0070] Eligibility criterion 5: The tradingId of the original payment transaction and the cancelled transaction must be different, confirming that it belongs to "cancellation in refund" rather than "cancellation in payment".

[0071] Eligibility 6: There must be original payment records and cancellation records, and neither of them must be empty.

[0072] Eligibility 7: The cash merchant configuration must exist (query the CASH type merchant configuration through merchantService), otherwise cash refund transactions cannot be created.

[0073] In this embodiment, when the refund from the individual medical insurance account to the medical insurance account fails, the original card payment cancellation record is first marked as a refund failure, and then an equivalent cash refund record is created as compensation. The payment method is changed to cash, and the medical insurance participation flag is set to not participate in medical insurance reimbursement calculation. The original card payment cancellation record and the new cash refund record both point to the same original card payment record through the association identifier field, forming a triangular association structure, supporting tracing the complete refund change history from any record. This embodiment ensures that patients' rights are not lost, eliminates uncertainties in the refund process, and provides complete reconciliation and audit traceability capabilities.

[0074] Example 2 The purpose of this embodiment is to provide a method for tracing transaction records when the cancellation of medical insurance personal account funds fails, including: The detection module is configured to detect whether the operation of refunding funds from the individual medical insurance account to the medical insurance account has failed, and whether the portion of the medical insurance pooled fund has been successfully withdrawn. The query module is configured to: if the operation of refunding medical insurance personal account funds to medical insurance account fails, and the medical insurance pooled fund part is successfully cancelled, then through the associated query, filter out the original card fund payment flow with the payment method of medical insurance personal account funds from all related flow flow related to the original payment, and query the corresponding original card fund cancellation flow based on the identification information of the original card fund payment flow. The update module is configured to: update the status information of the original card cancellation transaction to a refund failure status, update the payment type information of the original card cancellation transaction to a refund payment type, and record the failure reason information; The creation module is configured to: create a new cash refund transaction based on the refund amount of the original card cancellation transaction; wherein, the refund amount of the new cash refund transaction inherits the refund amount of the original card cancellation transaction, the payment method is set to cash type, the medical insurance participation identifier is set to not participate in medical insurance reimbursement calculation, and the status information is set to refund successful status; The association module is configured to associate the original card payment cancellation record and the new cash refund record with the same original card payment record through their respective association identifiers.

[0075] In further embodiments, the following is also provided: An electronic device includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor. When executed by the processor, the computer instructions perform the method described in Embodiment 1. For brevity, further details are omitted here.

[0076] It should be understood that in this embodiment, the processor can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0077] Memory may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of memory may also include non-volatile random access memory. For example, memory may also store information about the device type.

[0078] A computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the method described in Embodiment 1.

[0079] The method in Embodiment 1 can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor. The software modules can reside in readily available storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, a detailed description is not provided here.

[0080] A computer program product includes a computer program that, when executed by a processor, implements the method described in Embodiment 1.

[0081] The present invention also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in program modules, which execute in a device on a target real or virtual processor to perform the processes / methods described above. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided among program modules as needed. The machine-executable instructions for the program modules can execute within a local or distributed device. In a distributed device, the program modules can reside in both local and remote storage media.

[0082] The computer program code used to implement the methods of the present invention may be written in one or more programming languages. This computer program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the computer or other programmable data processing device, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a computer, partially on a computer, as a stand-alone software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.

[0083] In the context of this invention, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, and the like. Examples of signals may include electrical, optical, radio, sound, or other forms of propagation signals, such as carrier waves, infrared signals, etc.

[0084] Those skilled in the art will recognize that the units and algorithm steps described in conjunction with the embodiments herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0085] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A method for tracing transaction records when the cancellation of a medical insurance personal account fails, characterized in that, include: Check whether the process of transferring funds from the individual medical insurance account to the medical insurance account failed, and whether the portion from the medical insurance pooled fund was successfully withdrawn; If the refund of medical insurance personal account funds to medical insurance account fails, but the medical insurance pooled fund is successfully cancelled, the original card fund payment transaction with medical insurance personal account fund type will be screened out from all related transaction data related to the original payment through associated query, and the corresponding original card fund cancellation transaction will be obtained based on the identification information of the original card fund payment transaction. Update the status information of the original card cancellation transaction to "refund failed" and update the payment type information of the original card cancellation transaction to "refund payment type", while recording the reason for failure. Based on the refund amount of the original card cancellation transaction, a new cash refund transaction is created; wherein, the refund amount of the new cash refund transaction inherits the refund amount of the original card cancellation transaction, the payment method is set to cash, the medical insurance participation identifier is set to not participate in medical insurance reimbursement calculation, and the status information is set to refund successful. Both the original card cancellation transaction and the new cash refund transaction are associated with the same original card payment transaction through their respective association identifiers.

2. The method for tracing transaction records when the cancellation of a medical insurance personal account fails, as described in claim 1, is characterized in that... By performing a correlation query, the system filters out original card payment transactions with the payment method of medical insurance personal account funds from all related transaction records. Based on the identifier information of these original card payment transactions, the system then retrieves the corresponding original card cancellation transactions. Specifically: Use the primary key of the original payment transaction record as the query condition to retrieve all related transaction records; Filter records from all related transaction records that are identified as medical insurance personal account payment type to obtain the original card payment transaction records; Using the primary key identifier of the original card payment transaction record as the query condition, query the cancellation transaction record associated with the original card payment transaction record.

3. The method for tracing transaction records when the cancellation of a medical insurance personal account fails, as described in claim 1, is characterized in that... While updating the status information of the original card cancellation transaction to "refund failed," it also includes simultaneously updating the status information of other transactions associated with the original card cancellation transaction.

4. The method for tracing transaction records when the cancellation of a medical insurance personal account fails, as described in claim 1, is characterized in that... The associated identifier field value of the original card payment cancellation record is equal to the primary key identifier of the original card payment record, and the associated identifier field value of the new cash refund record is equal to the primary key identifier of the same original card payment record; using the primary key identifier of the original card payment record as the query condition, the original card payment cancellation record with a status of refund failure and the new cash refund record with a status of refund success are retrieved simultaneously.

5. The method for tracing transaction records when the cancellation of a medical insurance personal account fails, as described in claim 1, is characterized in that... This also includes the mandatory cancellation of the pooled fund portion, specifically: The medical insurance network settlement data is reversed, and the medical insurance network settlement record is marked as reversed. The cancellation result will be written back to the settlement service via the payment callback notification service; The status of the original unified payment record has been updated to "cancelled".

6. The method for tracing transaction records when the cancellation of a medical insurance personal account fails, as described in claim 1, is characterized in that... It also includes the following pre-detection conditions: detecting whether the modification type is a cancellation type; detecting whether the transaction type does not belong to the bedside settlement scenario; Check whether the transaction entity identifiers of the original payment record and the cancelled record are different to confirm whether the current operation belongs to the cancellation operation in the refund stage; check whether the payment method of the original payment record is the medical insurance pooled payment type.

7. A method for tracing transaction records when the cancellation of a medical insurance personal account fails, characterized in that, include: The detection module is configured to detect whether the operation of refunding funds from the individual medical insurance account to the medical insurance account has failed, and whether the portion of the medical insurance pooled fund has been successfully withdrawn. The query module is configured to: if the operation of refunding medical insurance personal account funds to medical insurance account fails, and the medical insurance pooled fund part is successfully cancelled, then through the associated query, filter out the original card fund payment flow with the payment method of medical insurance personal account funds from all related flow flow related to the original payment, and query the corresponding original card fund cancellation flow based on the identification information of the original card fund payment flow. The update module is configured to: update the status information of the original card cancellation transaction to a refund failure status, update the payment type information of the original card cancellation transaction to a refund payment type, and record the failure reason information; The creation module is configured to: create a new cash refund transaction based on the refund amount of the original card cancellation transaction; wherein, the refund amount of the new cash refund transaction inherits the refund amount of the original card cancellation transaction, the payment method is set to cash type, the medical insurance participation identifier is set to not participate in medical insurance reimbursement calculation, and the status information is set to refund successful status; The association module is configured to associate the original card payment cancellation record and the new cash refund record with the same original card payment record through their respective association identifiers.

8. An electronic device, characterized in that, It includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor, which, when executed by the processor, perform the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, Used to store computer instructions, which, when executed by a processor, perform the method described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the method described in any one of claims 1-6.

Images