Multi-tenant Procurement System with Dynamic Rule Configuration

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current e-commerce systems are not easily customizable for specific businesses or customers, requiring time-consuming and costly hard coding, which complicates the procurement process with complex business rules and order authorization requirements.

Innovation Solution

A procurement system using a single instance, multi-tenant architecture that includes an access module for user access, a search engine for product searches, a transaction module for processing requisitions, a business rules module for applying contractual terms, and a data repository for storing system data, allowing for efficient and customizable procurement processes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If current e-commerce systems are used, then basic procurement functionality is provided, but customization requires time-consuming and costly hard coding

Engineering Contradiction:
ImprovecustomizabilityVSAvoidimplementation time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The system uses dynamic configuration files (XML, JSON, YAML) that allow business rules, workflows, and parameters to be modified at runtime without recompiling or redeploying the application. This enables the procurement system to adapt to different organizational needs dynamically, resolving the contradiction between customizability and implementation time.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The invention changes the system from static hard-coded configurations to parameter-driven configurations through external configuration files. Business rules, approval workflows, vendor terms, and procurement parameters can be adjusted by changing configuration parameters rather than modifying source code, enabling rapid customization.

Inventive Principle:
Principle #35Parameter changes

2Adaptability or versatility

If hard coding is used for customization, then specific business requirements are met, but development costs increase

Engineering Contradiction:
Improvebusiness rule customizationVSAvoiddevelopment cost
Core Design Contradiction:
Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The system uses template-based configuration files that can be copied and reused across different organizations and departments. Standard procurement workflows, business rules, and parameters are defined once in configuration templates and can be instantiated multiple times with different parameters, eliminating the need to rewrite code for each customization scenario.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The configuration system provides universal functionality through a single codebase that can serve multiple procurement scenarios. The same core application with configurable parameters handles diverse business requirements including vendor management, approval workflows, contract terms, and procurement processes across different organizations without requiring separate custom-coded solutions.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Manufacturing precision

If complex business rules are implemented, then procurement accuracy is improved, but system complexity increases

Engineering Contradiction:
Improveprocurement accuracyVSAvoidsystem complexity
Core Design Contradiction:
Manufacturing precisionVSDevice complexity

Solution Approach 1:

The system segments complex procurement processes into discrete, configurable components including vendor management modules, approval workflow engines, contract term definitions, and business rule validators. Each component can be independently configured and managed through configuration files, making complex business rules more manageable and maintainable while preserving procurement accuracy.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The invention introduces configuration files as an intermediary layer between the user interface and the core business logic. This intermediary allows complex business rules to be defined and stored externally, separating the complexity from the application code and enabling precise control over procurement processes without increasing system complexity.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Productivity

If multiple tenants are supported in a single instance, then resource utilization is improved, but data isolation requirements increase

Engineering Contradiction:
Improveresource utilizationVSAvoiddata isolation
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The system adds a logical dimension for data isolation by introducing tenant identifiers and organization-specific configuration contexts. Rather than physically separating data across multiple instances, the system isolates data logically through configuration-based tenancy management, allowing multiple tenants to share the same physical infrastructure while maintaining data isolation through configuration parameters and namespace separation.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

Data Source

PatentUS12299732B2User-specific rule-based database querying
Publication Date: 2025.05.13 JAGGAER LLC
  • US12299732B2 patent drawing
  • US12299732B2 patent drawing
  • US12299732B2 patent drawing

AI summary

In an embodiment, a computer-implemented method operating at a server system is disclosed. The method includes associating business rules with a plurality of users, displaying a catalog item to a respective user of the plurality of users in accordance with the respective business rules associated with that user, and generating a purchase order for the displayed catalog item. Related methods and systems are also disclosed.