OLTP System Handling Multi-Supplier Refund Processing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional On-Line Transaction Processing (OLTP) systems face difficulties in processing transactions involving multiple products with different merchant structures, leading to errors and challenges in refund processing when multiple merchants are involved.
Innovation Solution
An OLTP system that processes transactions by identifying the merchant for each product within an itinerary, determining refund amounts, and facilitating refunds from either the seller or supplier side, using a transaction server that maintains a database to track payment structures and trigger refunds accordingly.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If conventional OLTP systems process transactions with multiple products having different merchant structures, then transaction processing capability is maintained, but processing errors occur and refund operations become problematic
Solution Approach 1:
The patent segments the transaction processing by identifying and separating different merchant structures for different products within a single transaction. The system divides the refund operation into product-level granularity, allowing each product to be processed according to its specific merchant structure (seller as merchant vs. supplier as merchant), thereby resolving the conflict between handling diverse transaction structures and maintaining processing accuracy
Solution Approach 2:
The patent applies local quality by enabling different merchant structures to coexist within a single transaction. Each product can have its own merchant designation (seller or supplier) based on local business requirements, while the overall transaction is processed cohesively. This allows the system to adapt to varying merchant arrangements for different products without compromising the integrity of the entire transaction
2Ease of operation
If the seller is designated as merchant for all products, then transaction processing is simplified, but the seller bears unnecessary payment risk and loses flexibility
Solution Approach 1:
The patent implements dynamics by making the merchant structure flexible and adaptable rather than static. The system can dynamically assign different merchant roles (seller or supplier) to different products based on business requirements, payment methods, and risk considerations. This dynamic approach allows the seller to be merchant for some products while the supplier is merchant for others, providing both operational simplicity and structural flexibility
3Adaptability or versatility
If different merchants are assigned to different products in a transaction, then transaction structuring flexibility is improved, but conventional systems produce processing errors and refund problems
Solution Approach 1:
The patent introduces an intermediary layer that manages the complexity of multiple merchant structures. The system acts as a mediator between the buyer, seller, and suppliers, coordinating refund operations across different merchant boundaries. This intermediary mechanism handles the complexity of tracking which product has which merchant structure and ensures proper refund routing without requiring the underlying system architecture to become overly complex
Data Source
AI summary
Systems, methods, and computer program products for an On-Line Transaction Processing (OLTP) system. Payment and merchant information is stored in a database record for each product in a set of products from multiple suppliers. In response to receiving a request to refund products in the set, the OLTP system may determine the merchant, a number of payments, and the amount of each payment for each product being refunded based on the payment and merchant information in the database record, and trigger payments between the supplier, seller, and buyer. In response to detecting an error, the OLTP system may store a status of the refund processing in the database record and queue the transaction for processing by a call center. In response to receiving a restart request, the OLTP system may retrieve the status data from the database record and restart processing of the refund based on the status data.