1. E-procurement Portal
  2. Features
  3. Supplier register
Feature · Supplier register

Supplier register

Supplier register for the procurement team and its reviewers.

OverviewSupplier Register
E-procurement Portal · Supplier register

Supplier Register

Suppliers

New
NameCodeContact nameAddressEligibility noteOrganization
Supplier 198CDE-333Contact 127A-21EN-329ORG-6223
Supplier 416CDE-951Contact 456K-7EN-771ORG-7070
Supplier 151CDE-324Contact 408U-15EN-243ORG-9066
Supplier 844CDE-587Contact 617E-4EN-677ORG-7483
Supplier 918CDE-119Contact 785V-23EN-497ORG-7552
6 of 6 records
Supplier 198Suppliers · SPP-77047
CodeCDE-333
Contact nameContact 127
AddressA-21
Eligibility noteEN-329
OrganizationORG-6223
Example screen with sample data

What you can do

Supplier register

App Administrator keeps a supplier code, name, active state, contact name, address and eligibility note under its buying organization. A Buyer chooses the counterparty on a purchase request from that register. The same identity stays linked as demand moves through review, ordering and receipt. The eligibility note gives the purchasing team context for its selection.

How the work is organized

  • Supplier identity. App Administrator maintains the code, contact and eligibility note within the buying organization.
  • Demand link. Buyer selects the supplier as the request counterparty and checks that the organizations agree.
  • Contact change. Update the supplier record so later requests use the current contact without losing the existing request link.

The register makes a supplier identifiable when names are similar. The code and organization answer which company was selected; the active setting and eligibility note tell the purchasing team what to check before sending a tender or placing an order. A change to contact details should leave the request linked to the same supplier identity. Have the App Administrator and Buyer open that link together during the pilot.

What to agree during setup

Agree who may activate a supplier, what the eligibility note should cover, and how contact changes are handled. Decide how organizations distinguish suppliers with similar names.

Choose one buying organization for the first cycle. Identify the person who can correct the record when the case fails a check. Write down the expected decision and evidence for the pilot before people begin using the queue. This makes it possible to distinguish a record awaiting action from a record that is ready to close.

Check the handoff on an actual case

Register a supplier for the pilot organization and add it to a request. Ask a second Buyer to identify the code, contact and eligibility note from the linked record. Update the contact and check that the request still points to the same supplier.

Ask the next person to open the same parent request and explain the next action from the record itself. They should point to the responsible owner, current status and supporting decision or receipt. If those disagree, return the case to the person who owns the correction and record the reason. Rehearse the failure route as well as the successful one.

What your team sees

  • Supplier Register — Check the active supplier code, contact and organization before selecting a counterparty.
  • Open Request Board — Open the request to confirm it points to that supplier.

What it keeps track of

Data model
Suppliers
Registered suppliers eligible to receive tender invitations and orders.
Organizations
Buying organizations that own procurement records.
Team members
Authenticated platform identities with a role inside an organization.

Who uses it

Permissions
App Administrator
Leads this part of the process.
Buyer
Carries operational records; Purchasing Approver reviews eligible decisions; Auditor reads the resulting evidence.

Set up E-procurement Portal your way.

Start free, then use Proto to change fields, steps and approvals before your team goes live.

How to get started