Supplier portal: from application to first order

A supplier portal should be designed by working back from the point at which a company can fulfil its first order, rather than starting with a registration form. A completed form does not yet mean that company details have been approved, the contract is valid or the business system permits procurement. For a distributor, retail chain or manufacturer, the value of a portal lies in a clear path between these states.

Start with eligibility rules, responsibilities and a verification transaction. Then decide whether a module in your ERP — enterprise resource planning system — is sufficient or whether you need a separate web portal. Below are selection criteria, the scope of the first version and checks to help you avoid turning correspondence into yet another queue of applications.

When a supplier portal makes business sense

A dedicated portal is useful when suppliers regularly submit documents, update information and address review comments, yet cannot tell where they stand in the onboarding process. The signal is not the number of suppliers itself, but recurring manual tasks: a procurement specialist asks again for a certificate, an accountant re-enters company details, or a manager searches someone else's inbox for an approval. First, document these inefficiencies using your own applications.

If there are few new partners, the process is short and the business system already supports external registration, separate development may be unnecessary. A configured approval workflow, a shared status register and someone responsible for each application can sometimes meet the need without a new product. A portal will not fix a situation in which departments have not yet agreed on who makes decisions.

Distinguish this process from a wholesale buyer's account: the buyer places orders, while the supplier submits information for procurement. Even with a shared login, their permissions and workflows differ.

First define what “approved to work with” means

Oracle's supplier registration documentation distinguishes prospective partners from companies authorised for procurement. The former need only minimal information for selection; the latter require more detailed information for contracts, orders and invoices. This is an example of how to organise the process, not a requirement to use Oracle.

Define states with verifiable outcomes

For your own process, you could start with the workflow “draft → submitted → clarification required → approved → activated in ERP → ready for a transaction”. Each transition has a condition, an owner and confirmation. “Approved” means the responsible people have completed their decision, while “activated” means a supplier identifier has been received from the business system. Do not combine them for the sake of an attractive progress indicator.

Describe rejection, withdrawal and resubmission separately. The supplier should see understandable feedback and a list of required actions, but not the finance or legal team's internal comments. Measure review time from an agreed event: the invitation, the first submission or receipt of a complete set of documents. Otherwise, comparisons between applications will be misleading.

Do not ask everyone for the same set of documents

Separate scenarios at least by procurement category and type of relationship. A goods supplier and a one-off service provider may need different fields and approvals. The responsible department must justify why each document is mandatory; your specialists determine the list of legal checks. Do not collect unnecessary information just because there is room left on the form.

How to choose between an ERP module and a separate web system

Compare solutions using an end-to-end scenario: submission, correction, approval and creation of a supplier record. Ask to see what happens when the business system fails, too — this is where manual support costs become apparent.

Drupal is an option for the web component when complex roles, multilingual capabilities and custom logic are needed. However, the platform itself does not define procurement rules or provide ready-made integration with every ERP. First check which capabilities your systems already have, and only then choose a technology for the unmet needs.

Which data the portal can change on its own

A single source of truth must be defined for each group of fields. In a typical project design, the portal stores the application draft and interaction history, while the ERP stores the approved supplier record. This is not a universal rule: what matters is documenting who owns the company name, tax identifiers, addresses, payment terms and bank details.

For example, changing a contact phone number and changing a bank account should not automatically follow the same workflow. The same Oracle documentation describes how to configure approvals for profile changes, including banking information. For your portal, the responsible people must separately determine which changes can take effect immediately, which require a decision and when the old version remains valid.

Create a small map for each field: source, format, validation, transfer direction, owner and conflict behaviour. A tax identifier helps find potential duplicates, but the uniqueness rule depends on the countries, legal entities and structure of your master data. A match should not trigger an unconditional automatic merge of records.

Do not confuse sending with a successful write

After approval, the portal must receive the processing result from the ERP. Until then, display a pending state rather than readiness to order. Provide for retransmission without creating a duplicate, an error log and someone responsible for investigating failed applications. If the business system is temporarily unavailable, the application must not disappear or silently move into a successful state.

Once the connection is restored, reconcile the application using its identifier and linked record. Confirm the data-exchange requirements in an ERP test environment.

Access boundaries matter more than the number of fields

Access control should be described through specific actions: who sees documents, who returns an application, who approves a change and who administers users. A supplier representative must not gain access to another company's information simply by knowing its file URL. Hiding a button in the interface is also no substitute for checking authorisation on the server.

OWASP recommends least privilege, denying access by default and checking permissions on every request. For a portal, this means checking not only the role, but also the user's relationship to the company and the specific application. Access requirements must be included in testing, not left as a verbal agreement.

Define how access is revoked for an employee who no longer represents a supplier, and how a new representative confirms their authority. Agree document retention periods, deletion and support access with those responsible for the data. The log should help reconstruct the sequence of decisions without becoming an unnecessary copy of sensitive information. This is a list of project questions, not confirmation that the system is secure.

How to test the first version before sending invitations at scale

Limit the pilot to one clearly defined supplier category and the complete workflow through to a verification transaction. Do not immediately add catalogue management, tenders and every procurement document. Otherwise, it will be difficult to separate registration problems from errors in related processes. Prepare test data and agree on a safe environment for the trial.

1. Document the initial process: events, responsible people, reasons for returning applications and the method for measuring time.
2. Test invitations, saving drafts and returning to them. Users should understand what information is still needed.
3. Submit incomplete data, receive review comments and resubmit the corrected application without losing its history.
4. Test approval by different roles and the absence of access between two test companies, including access to attachments.
5. Simulate ERP downtime, repeat the transfer and make sure that one correct record is created and the status matches the result.
6. Complete an agreed test order or another verification transaction. Check the required legal entity, terms and identifiers.
7. Give the support team failure-handling instructions, contact details for responsible people and rules for stopping new invitations.

Expand the pilot only after confirming the result in the connected system. Access errors, duplicates or incorrect authorisation for a transaction are reasons to stop. The rollback plan must preserve submitted applications and explain what happens next.

How to assess timelines, budget and results without relying on other people's benchmarks

The schedule depends on agreement on the rules, master data quality, the availability of a test ERP and the people who approve the data. Divide the plan into process definition, a prototype, data-exchange testing, implementation, a pilot and launch. Define the prerequisites and outcome of each stage. If integration access has not yet been tested, a fixed date for the entire launch remains an assumption.

Include business analysis, form design, roles, integration, migration of the necessary data, testing and support training in the budget. After launch, hosting, backups, updates, monitoring, licences and workflow changes will remain ongoing costs. Public information on GL.ua development costs does not replace a separate portal estimate: its scope is determined by the process and the number of systems, not the number of screens.

To assess the impact, record the time from complete submission to readiness, the proportion of applications not returned for correction, reasons for rejection and the number of manual interventions. Separate waiting for the supplier, internal approval and technical delays. Compare similar categories before and after the pilot. A universal industry timeframe will not tell you whether you have removed your own bottleneck.

What to prepare for a substantive conversation with a developer

Gather a state map, examples of anonymised applications, a list of mandatory fields, roles and a description of ERP data exchange. Add the readiness criterion for the first transaction and a list of exceptions. This package will let you compare proposals for the same scope, rather than different interpretations of a “portal”.

Start with the shortest manageable workflow: the supplier understands the next action, the responsible person sees their queue and the ERP confirms the result. If you need a separate web system, discuss portal development tailored to your business processes with GL.ua (Glyanets). Share your approval and integration map so the estimate is based on a specific task.