Procurement with a supplier portal

Before you start

• Build your first app
• Relations: how modules connect

You will build the buying side of a company in Beezr: a supplier is invited, a request for quotation (RFx) goes out, bids come back, the winner gets a contract and a purchase order, the goods are accepted, and only then can an invoice be raised. This is the same shape as the Vendor HUB demo workspace. The build takes a day of careful work for one person. Each piece below is a few minutes.

Here is the journey one purchase takes.

1. Vendor
2. RFx event
3. Bid
4. Contract and PO
5. Acceptance
6. Invoice

You need a workspace, a Designer account and the Quickstart behind you. The recipe tells you what to build, not every click. For the clicks, follow the links to the how-to pages.

What are we building?

Eight modules (the table below lists them), one application, three workflows and a handful of buttons. The buyers work in App space. Suppliers work in a separate portal that talks to the same records. The five parts:

• Modules hold each kind of record: vendors, RFx events, bids, contracts, purchase orders, acceptance notes and invoices.
• Relations link them, so a bid knows its RFx event and its vendor.
• Workflows approve the RFx event, issue the order and stop early invoices.
• Record page actions let a buyer start those workflows from the record.
• Permission profiles decide who sees which records.

Which modules and fields do I need?

Create the modules first, then the fields. Keep each module to one kind of record. The names below follow the Vendor HUB demo; yours can differ.

Module	Key fields	Type	Notes
Vendors	Name, Country, Status	Text, Lookup, Lookup	Status: Draft, Pending Approval, Active, Suspended, Blacklisted
Vendor Contacts	Full name, Email, Is primary	Text, Text, Boolean	Related to a vendor. The order email uses the primary contact
RFx Events	Title, RFx type, Status, Submission deadline, Estimated value, Evaluation method, Technical weight, Commercial weight	Text, Lookup, Lookup, Date time, Currency, Lookup, Decimal, Decimal	RFx type: RFI, RFQ, RFP, EOI. Status: Draft through Awarded
Bids	Total bid value, Status, Technical score, Commercial score	Decimal, Lookup, Decimal, Decimal	Status: Draft, Submitted, Under Technical Evaluation, Shortlisted, Awarded, Disqualified
Contracts	Contract number, Title, Contract value, Start date, End date, Status	Text, Text, Decimal, Date, Date, Lookup	Status: Draft, Published, Counter Signed, Active, Expired, Terminated
Purchase Orders	PO number, Total value, Delivery date required, Status	Text, Decimal, Date, Lookup	Status: Draft through Closed
Acceptance Notes	Acceptance status, Acceptance date, Inspection notes	Lookup, Date, Rich text	Acceptance status: Pending, Accepted, Accepted with Remarks, Rejected
Invoices	Invoice number, Gross amount, VAT amount, Match status, Approval status, Payment status, Invoice file	Text, Decimal, Decimal, Lookup, Lookup, Lookup, Content	Three separate statuses keep review and payment apart

Give each reference field a default value that numbers it for you. The demo does this with a Smart Script on the Default value of Contract number:

var pad = '00000';
var n = $AUTO_INCREMENT$;
var result = (pad+n).slice(-pad.length);
'CONTR'.concat('-').concat(result);

The last expression is the value, so the script has no return. Each new record gets CONTR-00001, CONTR-00002 and so on. Create the lookup lists under Lookups before you add the fields that use them. See Add a field and Create a lookup list.

Tip from a Beezr Consultant

Put the vendor’s invitation in its own module, with a Token field whose default value generates a random code. The demo’s Vendor Invite module does this with Java.type('java.util.UUID'). The supplier quotes the token when they register, so nobody types an ID.

How do the modules connect?

A relation lets one record point at another. Open the module that should hold the pointer and use the Relation button on its Fields page. Choose the related module, then a Display field that people will read, such as the vendor’s name.

On this module	Add a relation to
Bids	RFx Events, Vendors
Contracts	Vendors, Bids, RFx Events
Purchase Orders	Contracts, Vendors
Acceptance Notes	Purchase Orders, Vendors
Invoices	Purchase Orders, Acceptance Notes, Vendors

Once these exist, each parent record can show its children on a tab: a vendor’s bids, a contract’s purchase orders, a purchase order’s invoices. You add those tabs on the record page later. See Relations: how modules connect.

What do the forms and views look like?

Give each module a form with blocks that match how people think: Basic information, Dates, Commercial terms, Documents. Put the file fields (Invoice file, supporting documents) in their own block so the form stays short. On the Invoices form, set Match status and Payment status to read-only, so only workflows and finance change them. See Build a form and Make a field required, read-only or hidden.

For views, make these choices under Dataviews:

• Table on every module, with the reference number, status and amount as columns.
• Kanban on RFx Events, grouped by Status, and on Bids, grouped by Status. A board shows a buyer where everything stands.
• Schedule on RFx Events, with Starts on set to the submission deadline, so deadlines show on a calendar.

Give each status field a default value of Draft, so every new record lands in a column on the board.

○ ○ ○Beezr

×

The trigger starts the workflow when an RFx event is created.
The Approval task pauses the workflow until someone decides.
The Rejected path updates the record and stops.
The Approved path publishes the RFx event.
Check lists problems before you save.

Which workflows do I need?

Three workflows carry the process. Build them under Automation on the module that starts each one. The first is the approval you already know from the Quickstart.

Approve a new RFx event

On RFx Events, create a workflow that runs when A record is created, After the record is saved (POST).

Step	Setting
Approval task	Title people will see: New RFx. Who decides?: a role, such as Procurement Director
Record manager on Approved	Update RFx Events, set Status to Published
Record manager on Rejected	Update RFx Events, set Status to Draft

On the approval step, tick Add the rejection reason to the record and pick a Reason field, so the buyer reads why. Updating the record that started the workflow needs no key. See Approvals and tasks and Record manager.

Issue a purchase order

On Purchase Orders, create an Adhoc workflow. Adhoc means a button or another workflow starts it, and the Smart view button in the next section does exactly that.

1. Record manager: Update Purchase Orders, set Status to Issued.
2. Load data: Vendor Contacts where Vendor is the order’s vendor and Is primary is yes. Name the list primary_contact.
3. Send email: To is the primary_contact email. A token on a list reads its first record, so the primary contact is the one addressed.

If you add a purchase order document template, a Smart document step can attach the PDF. See Smart document.

Stop an invoice that has no accepted delivery

This is the rule that saves finance from exceptions. On Invoices, create a workflow that runs when A record is created, with timing Before the save, can stop it (PRE).

1. Add Load data. Choose Acceptance Notes. Add the rules Purchase Order is the invoice’s purchase order, and Acceptance status is Accepted. Name the list accepted_notes.
2. Add Decision. Pick the list accepted_notes itself and choose has no records.
3. On the Yes path, add Terminate. Choose Failed, and type the message This purchase order has no accepted delivery yet.
4. On the No path, leave the workflow to end. The save goes ahead.

When the Terminate runs as a failure, the save is blocked and the person sees your message. That is how a PRE workflow works: a clean ending lets the save continue, anything else stops it.

For a PRE workflow, choose the exact event. Create one PRE workflow for A record is created, and a second for A record is updated if edits must pass the same check.

See Before the save or after: PRE and POST workflows.

Which buttons go on the record page?

Open Smart views on Purchase Orders. Add action buttons under Actions. Each button runs a workflow, opens a form or a link. The demo’s purchase order page carries Submit for Approval and Issue PO.

○ ○ ○Beezr

×

Each action is a button on the record page, in this order.
The panel on the right edits one button or a group of buttons.
Save stores the record page.

Add these:

• On RFx Events: Publish, which runs an adhoc workflow, shown only while Status is Draft.
• On Bids: Technical Evaluation, Commercial Evaluation, Award Vendor, Initiate Contract. The last one creates a Contracts record from the bid, using a Record manager step with Create.
• On Purchase Orders: Issue PO.

Add Related tabs so a vendor shows its Bids, Contracts and Invoices, and a purchase order shows its Invoices and Acceptance Notes. See Add action buttons to a record page and Add related tabs.

○ ○ ○Beezr

×

The header facts are the contract, vendor and status.
Submit for Approval and Issue PO are the action buttons.
Related tabs list the invoices and acceptance notes of this order.

Who should see what?

Create permission profiles under Account settings › Users & Security › Permissions, then give each to a role.

Profile	Apps and modules	Records
Buyers	The procurement app. Create and edit on RFx Events, Bids, Contracts, Purchase Orders	Team records on, so a manager sees what their team created
Finance	Invoices and Purchase Orders. Edit on Invoices only	All records on Invoices
Approvers	The procurement app, view only	A rule on RFx Events: a record where I have an open task

Team records adds records created by people under the person in the org chart, so build the org chart too. Permissions are loaded when someone signs in, so a change reaches people at their next sign-in. If they cannot see something, read Check access to records and apps.

○ ○ ○Beezr

×

Tick the apps this profile can open and choose the landing app.
Team records adds records created by people below in the org chart.
The Records column opens the record rules for a module.

How do suppliers get in?

The supplier portal in this story is a separate web application outside Beezr, so suppliers never need a Designer or App space account. It works with the same modules as the buyers.

What the portal does with those records:

1. A supplier registers with the invitation token, and the portal creates a Vendors record in Draft.
2. Documents arrive on a Vendor Documents module, linked to the vendor.
3. A buyer approves the vendor in App space. The portal shows the new status.
4. The supplier answers an RFx event by creating a Bids record, and later raises an Invoices record.

Step 4 is where the PRE workflow earns its keep: the portal receives the message from Terminate if it tries to invoice early.

The portal saves records the same way App space does. PRE and POST workflows fire for portal writes too, so your rules apply to suppliers without any extra work.

What can I change?

• Three-way matching. Add a Smart field or a Custom function on Invoices that compares the invoice with the order and the accepted quantity, and writes Match status. See Custom function.
• Approval by amount. Add a Decision before the approval: above a threshold, ask a second role. An approvals hub shows how.
• Post to your accounting system. A REST API step or an Integration step sends the approved invoice on. See Talking to any system.
• Contract reminders. A schedule on a workflow runs every day. Load contracts that end within 30 days and send an email for each one. See Run a workflow on a schedule.
• Arabic. Translate labels under Labels so buyers and suppliers each read their own language. See Translate your app into Arabic.

Where can I see the finished story?

The Solutions page tells the same journey from the supplier’s chair, with the screens: Procurement and suppliers. The supplier side has its own page: Supplier portal.