Managing Registration Updates

Admins review pending update requests under Registration Form Update Request, check the requested change and any supporting documents, then mark it Approved or Rejected with a written remark that becomes part of the permanent record.

Detailed step-by-step for approvers:

1. Open the Registration Form Update Request list from the Vendor Registration & Approval module.
2. Identify requests with status Active — these are pending review and require action.
3. Click the row to open the full request, including the Reason for Updation, the specific Detailes To Be Updated tags (e.g., Company Details, Bank Details, GST Details), and the Requester name.
4. Review any attached Supporting Document — for sensitive categories like Bank Details or GST Details, this should be a formal proof (cancelled cheque, updated GST certificate, etc.).
5. Cross-check the requested change against existing vendor records for consistency — for example, does the new bank account name match the company name on file?
6. Add a clear Approval Remark explaining your decision — examples from real use include simple confirmations like "OK" or more detailed notes like "okay you can update."
7. Change the status to Approved (which triggers the underlying vendor record update) or Rejected (which leaves the original data untouched).

Why this creates a clean audit trail: Every change to a vendor's core data — bank details, GST, address, contact person — is logged with a documented reason, a named requester, supporting evidence, and a reviewer's remark. This is far safer than allowing silent edits directly on the master vendor record, especially for financially sensitive fields like Bank Details.

Best practices for reviewers:

• Never approve a Bank Details or GST Details change without a supporting document attached.
• If a reason is vague (e.g., just "update form" with no explanation), request clarification before approving.
• Keep remarks specific enough that a future audit can understand exactly why the change was approved.
• Prioritize requests that block active transactions — for example, a Bank Details update tied to an upcoming payment should be reviewed faster than a routine cosmetic company detail change.

Frequently Asked Questions

Can more than one person review the same update request? 

Typically one designated approver role handles this, though visibility into the request list may be shared among the admin team.

What happens to the old data after an update is approved? 

The vendor's master record is updated to reflect the new information; historical update requests remain in the log for audit purposes.

Is there a way to request more information from the vendor before deciding? 

Yes — leaving the request in Active status while communicating separately (via chat, email, or the Feedback & Complaints channel) is common practice before making a final decision.

Do rejected requests notify the vendor automatically? 

The status change and Approval Remark are visible to the requester in the same list, effectively communicating the decision and reasoning.

Can an approved update request be reversed later? 

If an error is discovered, a new update request should be raised to correct it — this preserves the audit trail rather than editing history silently.

Should the Approval Remark be visible to the vendor, or only internal staff? 

Since the remark appears directly in the same list the requester (vendor or internal staff) submitted from, it's designed to be visible to them as the direct response to their request.