The Supplier Side: Order Commitments, Team Access and Integrations

On an issued purchase order in the supplier portal, Acknowledge this order asks for a Promised delivery date, a Note to your customer, and an answer for each line: confirmed in full, part now with the rest backordered, all backordered, or cannot supply. A backordered line takes the Backordered qty and when it ships. Press Acknowledge order. Coming back later shows Your delivery commitment with Update commitment, and every change is visible to the buyer. If the order cannot be taken at all, Cannot take this order? with a reason and Decline order says so.

On the buyer’s purchase order, the Supplier commitment and messages card shows the promised date and each line’s answer, and flags what needs attention: a promise later than the order’s due date, and every partial, backordered or unavailable line. The buyer is told in the bell when the supplier acknowledges, changes the promise or writes. Before this, the web portal had no accept button at all; acknowledging now works the same on the web, in the app and through the API.

Shipment notices come after acknowledging. Send a shipment notice takes a Delivery note number, Shipped on, Expected to arrive, Carrier and tracking number, a delivery note as a PDF or photo, and the quantities in this shipment, never more of a line than is still unadvised. The order moves to in transit. In practice: a Thika packaging maker acknowledges an order for 20,000 cartons, confirms 12,000 for the 10th and backorders 8,000 for the 24th, then sends a notice for the first load with the driver’s delivery note photographed.

Every order has one thread: Messages with your customer on the supplier side, Messages with the supplier on the buyer’s. Either side writes, and either side can tick Raise this as a dispute. The other side is told: the buyer in the bell, the supplier by email unless they turned off Order issues and messages in their preferences. Everything stays on the order, so the conversation about a short delivery sits beside the delivery itself.

Only the buyer resolves a dispute, and only someone who can approve purchase orders. Resolve takes a note, such as “Credit note CN-114 agreed for the damaged cartons”, and the supplier sees the outcome. A dispute does not change the order, the receipt or the bill by itself; it records what was agreed so the person who acts on it, raising a debit note or receiving the replacement, has the reason in front of them.

In practice: a Moshi coffee exporter receives jute bags where two bales are torn. The storekeeper records them as damaged on the receive screen; the buyer writes “Two bales torn, please replace with the next load” and raises it as a dispute. The supplier replies that replacements will ship Thursday; when they arrive, the buyer resolves the dispute with the replacement delivery note number.

Email preferences in the portal has a switch for each business email: Invitations to quote, Quotation decisions, New purchase orders, Document requests, Order issues and messages, and Payments. All start on. The choice is checked when the email is actually sent, not when it was queued, and everything stays visible in the portal either way. Sign-in codes, password resets, invitations and changes to payment details are always sent, because they protect the account. Any contact can see the preferences; only one who can manage contacts can change them.

Team lists the colleagues who sign in for the company. Invite a colleague with a name and email; they get a link to set their own password. Tick only the access they need: Quote on RFQs, Purchase orders, Upload invoices, View payments, Company documents, Manage contacts. The primary contact holds all of them and cannot be removed, and only the primary contact can grant Manage contacts. Without View payments, payment amounts are hidden; the menu hides what a contact cannot use, and the server refuses it anyway.

Sign-in and sessions lists every browser with its IP address, country, first seen and last active, and every app sign-in and integration token. Sign out one, or Sign out everywhere else. A sign-in from a new browser or app, or from a new country, sends the contact an alert email that cannot be switched off, and shows a New sign-in banner with This was me or Sign it out. In practice: a Lusaka electrical wholesaler’s sales rep only quotes; the accountant uploads invoices and sees payments; the owner is primary and the only one who can add staff.

Integrations in the portal is for a supplier’s own ERP or warehouse system. Create token takes a Token name, an expiry (never, or 30, 90, 180 days or a year) and the scopes it may use: reading RFQ invitations, submitting quotations, reading orders, acknowledging orders, sending shipment notices, submitting invoices and proposing contract prices. The token is shown once and stored only as a hash. It acts as the contact who created it, with only its scopes, so it can never do more than that person could; if their access is removed or the company is switched off, the token stops too. Each token is limited to 60 requests a minute and 1,500 an hour.

Webhooks post events to the supplier’s HTTPS address: an RFQ invitation, a purchase order issued, a purchase order changed when a change order is approved, and a payment made. Each is signed with HMAC-SHA256 in the X-Awra-Signature header using a secret shown once. If the address does not answer with a 2xx, delivery is retried for about four hours; after 25 failures in a row the webhook is switched off. The Delivery log shows every event, its attempts and the response, and Test sends a sample. The full API reference is on the same page.

Contract prices shows the prices agreed on the supplier’s active contracts. Propose price takes a new price, the date it applies From, a lead time and a Reason, such as “Steel surcharge from 1 November”. Nothing changes until the buyer approves it under Supplier price proposals, reached from Supplier contracts; approval writes the new price and lead time to the contract. Setting up tokens and webhooks is on the web portal; a buyer can approve proposals on the web or in the app.