Vendor Management System — Proposal
Incorrect credentials. Please try again.
Confidential · Trinesis Technologies Pvt. Ltd.

NAGA LIMITED

Vendor Management System — End-to-End Workflow

Vendor Onboarding → Sourcing → PO → Receipt → Invoice → Payment → Scorecard

Process Flow

27 June 2026

8 STAGES · 8 CONTROL GATES

How to read this diagram

Swimlane — who performs the step
Vendor Procurement / Buyer Approver / Mgmt Stores / Gate / Quality Finance / Treasury System / AI SAP
Node type
🤖 AI / OCR step Decision (branches / rework loop) 🔒 Control Gate (must pass to proceed) 💾 SAP transaction Feedback / improvement loop
START · Vendor identified / requirement arises
1

Vendor Onboarding & Master Governance

🔒 Vendor Gate
Invite vendor & share registration link
iProcurement shares a registration link with a shortlisted vendor (portal, email or WhatsApp). Trigger-based — vendors cannot self-enrol from a public page.
Buyer

Trigger-based; link sent to potential vendor via portal / email / WhatsApp.

Vendor self-registration (KYC + documents)
iKYC = Know Your Customer. The vendor enters legal, bank and tax details and uploads statutory documents — PAN, GST, MSME, FSSAI, bank proof — on the portal.
Vendor

PAN, GST, MSME, FSSAI, bank proof, statutory certs uploaded on the portal.

Capture vendor material codes
iThe vendor also uploads their own material codes / part descriptions (any format). AI maps each to Naga's SAP material code so future receipts auto-match — see Smart Material-Code Mapping.
Vendor

Vendor part codes/descriptions uploaded & AI-mapped to SAP material master (mandatory).

🤖 OCR extraction + duplicate & field validation
iOCR = Optical Character Recognition. AI reads the uploaded documents, pulls out the key fields, and checks for duplicate vendors using PAN, GSTIN, bank account and name.
AI / OCR

Extract & compare GST/PAN/bank/name; duplicate check on PAN, GSTIN, bank a/c.

Data valid & non-duplicate?
iCheckpoint: if a field is wrong, missing, or a duplicate is found, the request is returned to the vendor to fix. Only clean records move forward.
Decision
↻ No / mismatchReturned to vendor for correction — re-upload right document.
✓ YesProceed to external validation & review.
🤖 External validation (GST active · IFSC / bank)
iAutomated checks against authoritative sources — e.g. is the GST number active, does the IFSC/bank account exist — via approved government and bank APIs.
AI / API

Automated status checks via approved government / bank APIs (where legally available).

Multi-stage review & approval
iSequential human review by Purchase, Finance, Tax, Quality and Compliance. Phased: manual at first; once AI proves reliable, clean cases auto-approve and only flagged ones reach reviewers.
Approvers

Purchase → Finance → Tax → Quality → Compliance, risk rating & rework. Phased: manual first, then AI auto-approves clean cases.

Approved?
iFinal onboarding decision. If rejected, the vendor is notified with a reason. If approved, the master record is created in SAP.
Decision
✗ RejectedVendor notified with reason; onboarding closed / reworked.
✓ ApprovedCreate master in SAP.
💾 Create Vendor / Business Partner (maker-checker)
iThe final maker-checker sits in VMS. Once approved there, the master posts to SAP — no separate SAP-side maker-checker is needed. No master is created outside this audited workflow.
SAP

Maker-checker is in VMS; on final approval the master posts to SAP (no second SAP-side check).

🔒
Control Gate · Vendor Gate

Only approved, valid, non-blocked vendors are selectable downstream. SAP vendor number returned to vendor.

2

Demand → RFQ & Sourcing

🔒 Sourcing Gate
Purchase Requisition raised (budget check)
iPR = Purchase Requisition. MRP materials: PR is raised in SAP (auto from min/max) and pulled into VMS. Non-MRP materials: PR is raised directly in VMS — blocked/alerted if the material already has SAP MRP.
User Dept

MRP: PR raised in SAP → pulled to VMS. Non-MRP: PR raised in VMS (blocked if material has SAP MRP).

🤖 Demand consolidation + eligible-vendor proposal
iAI groups similar requirements across divisions to buy in bulk (better price) and proposes eligible vendors by category, risk and past score.
AI

Aggregate similar demand across divisions; propose vendors by category, risk & score.

Buyer confirms invitees & RFQ rules
iRFQ = Request for Quotation. The buyer confirms which vendors to invite and the rules — minimum number of quotes, closing date, sealed-bid visibility.
Buyer

Min-quote count, bid-close date, sealed-bid visibility per policy.

🔒
Control Gate · Sourcing Gate

Required number of quotes + technical approval, or deviation approved.

RFQ issued (portal + email / WhatsApp)
iThe RFQ goes out to vendors. The portal is the controlled channel for responses; WhatsApp/email are only alerts.
System

Portal is the controlled response channel; WhatsApp/email as alert.

Vendors submit sealed quotations
iVendors submit quotes — price, freight, tax, lead time, warranty, payment terms, documents — before the closing date. Sealed = hidden from others until bid close.
Vendor

Price, freight, tax, lead time, warranty, payment terms, documents — before close.

3

Comparison, Landed Cost & Negotiation → Award

🔒 Price Gate
🤖 Landed-cost normalisation & ranking (first)
iThis runs first, as soon as quotations are in: landed cost = basic + freight + packing + tax/duty + the rupee value of the credit period (cost-of-funds). AI normalises and ranks all vendors and suggests the best — before the human technical/commercial review.
AI

Runs first — basic + freight + packing + tax/duty + credit-period→₹; AI ranks & suggests best.

⚟ Runs in parallel — after the AI suggestion
Technical evaluation
iQuality/User department checks specification, warranty and compliance. This team cannot see or change the commercial (price) bids, keeping evaluation fair.
Quality / User

Specification, warranty, compliance — cannot alter commercial bids.

Commercial evaluation
iA separate buyer team evaluates price and commercial terms — kept apart from technical evaluation so neither side can influence the other.
Buyer

Price & commercial terms — separate team from technical.

⚞ Merge
Negotiation rounds → revised quotes resubmitted
iNegotiation calls are placed and recorded inside VMS (transcribed; vendor phone numbers masked). AI shows cross-division rates, history and targets on screen. The revised quote is re-entered and re-ranked. Every round retained for audit.
Buyer / Vendor

Calls placed & recorded in-VMS (transcribed, numbers masked); AI shows targets. Revised quote re-enters & re-ranked.

Non-lowest selection or price increase?
iIf the buyer wants a vendor who isn't the cheapest, or a price has risen, the system forces a recorded reason and approval before continuing.
Decision
✓ Lowest / within limitProceed to award.
⚠ YesMandatory reason + approval (Price Gate).
🔒
Control Gate · Price Gate

Price increase, high-value & non-lowest selection require reason + approval.

Award decision — split / item-wise / non-lowest
iThe order can be awarded flexibly — split across vendors, item-by-item, or to a non-cheapest vendor (with approval). The agreed price is locked as the savings baseline.
Approvers

Flexible award with approval; baseline locked for savings measurement.

Regret communication to unsuccessful vendors
iVendors who were not selected are automatically notified of the outcome, often with a note on where to improve next time.
System

Auto-notify non-selected bidders (outcome + improvement note).

4

PO Creation & Release

🔒 PO Gate
💾 PO created from approved award
iPO = Purchase Order: the formal order, created in SAP from the approved award.
SAP

Award data handed to SAP purchasing document.

🤖 PO validation vs quotation & approval
iAI checks the PO against the winning quotation and approvals — price, quantity, unit, tax, payment term, warranty, vendor/GSTIN and quotation validity.
AI

Price, qty, UoM, tax, payment term, warranty, vendor/GSTIN, quotation validity.

🔒
Control Gate · PO Gate

Stock, open PO, consumption, budget, approved source & terms shown before release.

PO release (value-based approval levels)
iThe PO is approved through value-based approval levels, then issued to the vendor via portal + WhatsApp/email.
Approvers

Released & issued to vendor via portal + WhatsApp / email.

5

ASN, Gate Entry & Goods Receipt

🔒 Receipt Gate
Vendor submits ASN + uploads invoice
iASN = Advance Shipping Notice: the vendor tells Naga what has been dispatched before it arrives — dispatch date, vehicle, packing list, expected delivery — and uploads the invoice.
Vendor

Dispatch date, vehicle/transport, packing list, expected delivery.

Gate entry — vehicle/driver + invoice scan
iAt the factory gate, security captures the vehicle and driver details and scans the vendor invoice and supporting documents.
Stores / Gate

Capture vehicle no., driver mobile; scan vendor invoice & supporting docs.

🤖 OCR invoice vs SAP PO + gate seal
iAI reads the scanned invoice and matches it to the SAP PO — vendor, GSTIN, division, material, PO number, e-way bill, e-invoice, weighment slip and gate seal.
AI / OCR

Vendor, GSTIN, division, material, PO no., e-way/e-invoice, weighment, seal colour/VA no.

Physical verification — shortage / excess / damage
iStores physically counts and inspects the goods, recording any shortage, excess or damage against the invoice and PO.
Stores

Received qty / condition compared with invoice & PO.

Quality & quantity OK?
iIf quantity or quality fails, a debit note or rejection is raised with evidence. If OK, the goods proceed to receipt posting.
Decision
✓ OKAccept & proceed to receipt posting.
⚠ OK with conditionAccept at reduced price + credit note.
✗ Not OKReturn + debit note / purchase return (e-invoice).
↻  Post-production return — defects found days after receipt trigger a separate return-to-vendor flow (debit note / purchase return).
🔒
Control Gate · Receipt Gate

ASN, gate entry, GRN, batch & quality status linked to PO.

💾 GRN / MIGO (or ML81N service entry)
iGRN = Goods Receipt Note. In SAP this is the MIGO transaction (or ML81N for services) — the official record that goods were received.
SAP

Goods receipt auto-created on approval.

6

Invoice Capture & 3-Way Match

🔒 Invoice Gate
Invoice submitted (PO or Non-PO Pro-screen)
iPO invoices flow here. Non-PO (expense) invoices follow a separate flow with three scenarios — pay the vendor directly, pay an employee-vendor, or reimbursement with ITC — to be finalised in Discovery.
Stores / Vendor

PO invoices here; Non-PO = separate flow (vendor · employee-vendor · reimbursement/ITC), finalised in Discovery.

🤖 OCR + duplicate check + 3-way match
i3-way match = checking the Invoice against the PO and the GRN (goods received) on quantity, rate, tax and tolerance. AI also blocks duplicate invoices (financial year + vendor + invoice number).
AI

FY + vendor + invoice no. dedup; PO ↔ GRN ↔ Invoice on qty / rate / tax / tolerance.

Match within tolerance?
iIf the three documents disagree beyond tolerance, an exception is routed to the right team with an owner, reason and deadline (SLA). If they match, it posts.
Decision
↻ MismatchException routed to Purchase / Stores / Tax / Finance with owner, reason & SLA.
✓ MatchProceed to posting.
🔒
Control Gate · Invoice Gate

Validated vs PO, GRN & tolerance rules; TDS / HSN / GST checked before posting.

💾 MIR7 simulation → MIRO posting (FB60 / FB65 non-PO)
iSAP steps: MIR7 parks and simulates the invoice (an accounting pre-check); MIRO posts it. FB60/FB65 are used for Non-PO invoices and credit memos.
SAP

GL simulation retained before final posting.

7

Payment Validation & Execution

🔒 Payment Gate
Due-date & ageing calc — Non-Due / Due / Over-Due
iThe system calculates each invoice's due date and sorts payments into Non-Due, Due and Over-Due, flagging early-payment cash-discount opportunities.
System

Baseline date + payment term; early-payment-discount opportunity flagged.

🤖 Open-item review & invoice grouping
iAI reviews the vendor ledger — outstanding advances, debit/credit notes — and groups same-vendor invoices. Bank balance (fund position) is shown read-only.
AI

Advances, debit/credit notes, same-vendor grouping; fund-position shown (read-only).

Maker-checker — Payable Supervisor → Payable Head
iTwo-person control: a Payable Supervisor prepares and the Payable Head approves, both seeing the full comparison, advances and bank balance in one view.
Finance

Review with comparison, advances & bank balance in one view.

Approve / Hold / Reject?
iThe payment can be approved, held or rejected — a hold or reject needs a mandatory reason and routes back or notifies the vendor.
Decision
↻ Hold / RejectMandatory reason captured; routed back / vendor notified.
✓ ApproveGenerate payment voucher.
🔒
Control Gate · Payment Gate

Due date, advance balance, debit/credit notes, discount & approval considered before payment.

💾 Payment voucher (F-53) → bank → UTR update
iUTR = Unique Transaction Reference (the bank payment reference). SAP generates the payment voucher (F-53), the bank pays, and the UTR is captured back.
SAP

Payment executes in authorised SAP / bank process; UTR returned to VMS.

UTR / payment status communicated to vendor
iThe payment confirmation and UTR are shared with the vendor via portal + WhatsApp/email.
System

Via portal + WhatsApp / email.

8

Vendor Scorecard & Savings Capture

🔒 Performance Gate
Capture delivery / price / quality / compliance / service data
iDelivery, price, quality, compliance and service data from the whole cycle are collected to score the vendor.
System

Transaction data collected across the cycle for scoring.

🤖 Weighted vendor scorecard + risk band
iA weighted vendor scorecard and risk band — price 25%, quality 25%, on-time delivery 20%, credit 10%, compliance 10%, service 5%, documentation 5%.
AI

Price 25 · quality 25 · OTD 20 · credit 10 · compliance 10 · service 5 · docs 5.

🔒
Control Gate · Performance Gate

Score & risk feed vendor eligibility for the next sourcing cycle.

🤖 Savings auto-attribution & finance validation
iEach saving is linked automatically to its baseline, formula, owner and evidence, then validated by Finance — preventing double-counting across modules.
Finance

Each saving linked to baseline, formula, owner, evidence & approval; no duplicate claims.

Executive 5% cost-benefit dashboard
iThe management view of the 5% savings target: identified -> approved -> realised -> finance-validated, with drill-down to the underlying SAP transaction.
System

Identified → approved → realised → finance-validated, with drill-down to SAP.

🏁 Benefit realised & reconciled to SAP
↻  Continuous loop — vendor score & savings baseline feed the next sourcing cycle (back to Stage 2).