Consignment Inventory Allocation Mechanism for Real-Time Locking

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In consignment processing, existing computer systems face issues such as duplicate provision of inventory and inefficient management of allocation requests, leading to potential stock shortages and errors due to asynchronous message exchange and lack of real-time inventory locking.

Innovation Solution

Implementing a system that locks and allocates inventory in real-time, using a synchronous call to reserve inventory tentatively, and releasing it if the user decides not to save the document, while ensuring that only one user can allocate inventory for a product at a time, and using asynchronous messages for confirmation or compensation based on document saving status.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If asynchronous message exchange is used for inventory allocation, then system flexibility and decoupling are improved, but duplicate inventory provision and stock shortages occur due to lack of real-time coordination

Engineering Contradiction:
Improvesystem flexibilityVSAvoidinventory allocation accuracy
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The system performs preliminary inventory locking when an allocation request is received, reserving the inventory before the asynchronous message is sent. This ensures that the inventory is not allocated to multiple requests simultaneously, preventing duplicate provision while maintaining system flexibility through asynchronous communication.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If real-time inventory locking is implemented, then duplicate allocation is prevented and reliability is improved, but system complexity and processing overhead increase

Engineering Contradiction:
Improveinventory allocation accuracyVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system introduces an intermediary inventory locking mechanism that mediates between allocation requests and actual inventory deduction. This intermediary layer coordinates allocation requests, ensuring reliability through real-time locking while managing system complexity by centralizing the coordination logic in a controlled manner.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Measurement precision

If inventory is locked tentatively and released on document cancellation, then allocation accuracy is improved, but additional processing steps and time are required

Engineering Contradiction:
Improveallocation accuracyVSAvoidprocessing time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The system implements dynamic inventory locking where the lock state changes based on document status. Inventory is locked tentatively when allocation is requested, and automatically released when the document is cancelled or saved. This dynamic approach ensures allocation accuracy while minimizing processing time by automatically managing lock states based on business events.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS11908000B2Allocation mechanism in consignment processing
Publication Date: 2024.02.20 SAP SE
  • US11908000B2 patent drawing
  • US11908000B2 patent drawing
  • US11908000B2 patent drawing

AI summary

In an example embodiment, when a user creates a consignment issue item for a given product in a sales order, the system will reserve/temporarily allocate the available quantity in consignment stock. A synchronous call to lock the inventor makes a tentative update to the inventory stock on the quantity required for the request product on the created issue item. This update is tentative because the locked quantity should be released if the user decides not to save the document, but it also should be locked so that it is not available to another user who is also trying to create an issue item in a different sales order document for the same product in a parallel session. The allocation may also change several times before saving the document by additional synchronous calls that again update the tentative allocations. When the user finally decides the final state of the issue item, it asynchronously sends either a confirmation or compensate message based on whether the document was saved or not saved.