Stage 1 — Record Initiation & Prospect Creation

This stage covers the initial creation of a vendor prospect record in VMDM, from search through to persistence and event publication.

Architecture Flow

1. Vendor Search & Initiation

The vendor onboarding process is initiated when a procurement user searches the VMDM system using key business identifiers:

• Trading Name
• Address
• Tax Information

This ensures existing vendor records are identified before any new creation attempt.

Scenario	Action
Record found	Update existing entry
No record found	Initiate new vendor prospect

Minimum Required Data

At initiation, users must provide these foundational attributes per country-specific SOP:

• Trading name
• Address
• Tax ID

2. Country-Specific Validation

Upon data entry, the system enforces country-specific business rules:

Validation Type	Description
Tax Format	Country-specific tax ID patterns (regex)
Address Structure	Required address fields per country
Mandatory Fields	Country-specific required attributes
Format Checks	Regex-based pattern validation

warning

Validation failures result in immediate feedback. Progression is restricted until data quality standards are met.

3. Duplicate Detection & Enrichment

Matching Logic

The system performs matching based on:

• Name similarity
• Tax ID
• Address similarity

Match Result	System Behavior
100% Match	Immediate termination — redirect to existing record
Partial Match (less than 100%)	Controlled progression with user acknowledgment
No Match	Continue without restriction

External Enrichment

In parallel, the system integrates with external providers:

Provider	Data Enriched
D&B	DUNS number, hierarchy
BVD	BVD ID, legal entity name

Enrichment appends:

• Legal entity name
• Corporate hierarchy
• Website metadata

4. Draft Submission (Synchronous Processing)

Upon user-triggered Save, the Draft API is invoked synchronously:

1. Stage-specific mandatory validation
2. Additional format checks
3. Lightweight duplicate re-evaluation

Outcome	Action
Validation fails	Abort request, return error
100% duplicate (BLOCK policy)	Abort request
ALLOW policy or no duplicate	Proceed to persistence

A system-generated Vendor ID is assigned with status: PENDING

5. Ingestion & Final Validation

The Ingest API orchestrates:

• Final validation
• Duplicate verification
• Business rule enforcement

This layer performs deeper consistency checks and ensures governance compliance.

6. Persistence & Search Optimization

Upon successful validation, the record is:

System	Purpose
PostgreSQL	Transactional storage (system of record)
Elasticsearch	High-performance search and retrieval

This dual-storage approach ensures both data integrity and optimised query performance.

7. Event Publication & Downstream Propagation

After successful persistence, the system publishes:

Topic	Purpose
Vendor Data Kafka Topic	Vendor lifecycle events
Notification Topic	Stakeholder notifications

These events are consumed by downstream systems:

• CIAM
• ASSP
• Minerva

This enables asynchronous synchronisation, workflow triggering, and stakeholder notifications in alignment with the event-driven architecture.