This vendor is late every time, and the person who knew that has left.
The vendor record has an address, a payment term and a contact who may or may not still work there. What it does not have is the part that mattered: that they quote four days and deliver in nine, that the price on the last order was negotiated for a quantity nobody buys any more, that the invoices go to a different email than the purchase orders. All of that was real knowledge, and all of it lived in one buyer's head, which is a storage medium with a notice period.
What you get with vendor management
A vendor record that carries the buying relationship, not just the address. Each vendor holds its own trading currency, a named responsible buyer, a payment term, a payable account, bank details, and an order warning, a message or a hard block, your choice per vendor, that appears at the moment somebody puts that vendor on an order. Receipt reminders are a switch on the same record, with the number of days before expected arrival.
Prices live where the buyer meets them. Each vendor-product row carries a price and a computed discounted price, a percentage discount, a minimum quantity, a unit of measure, a delivery lead time in days, a validity window with its own start and end dates, and the vendor's own product code and name for the same item. When something needs buying, the system filters those rows by vendor, quantity, date and unit of measure, and takes the qualifying row with the lowest discounted price converted into your company currency, so the buyer does not have to know which agreement is current. Confirming an order adds a vendor to a product it was not yet listed against, at the order price, while that product has ten vendors or fewer.
Performance is measured rather than remembered. On-time delivery rate is a computed field on the vendor record: over a rolling window, a year unless you change it, it takes the vendor's order lines, looks at the stock moves that completed against them, counts the quantity that arrived on or before the promised date, and divides by the quantity ordered. A vendor with no history reads as no data rather than as zero. The same measure opens as an On-time Delivery report broken down by vendor, product and product category, where grouping produces a quantity-weighted rate rather than an average of averages. Alongside it, Purchase Analysis reports spend and cycle time from the same data: total and average value, line counts, and the ordered, received and billed quantities, by vendor and by commercial entity.
Where vendor management comes from
It's already in Odoo, nothing to add, no upgrade tier to reach, no extra fee per user, and it runs on infrastructure you own. The vendor master, the vendor pricelists and the delivery-performance measurement are all in the base system, not held back for a higher edition. NetSuite bills procurement as a module and a per-seat renewal; in Odoo it is already included, and that difference is the product. (Three things do sit outside it, worth knowing before you sign: there is no multi-factor vendor scorecard, on-time delivery is the one metric the product computes, no supplier portal, and no rebate or commission model. The FAQ below weighs scoring against measuring, which is the first of those.)
What is a vendor master record, and what belongs in it?
A vendor master record is the single place a company holds everything about a supplier that more than one process needs: the legal and remittance details, the payment terms, the tax and banking information, the people to contact, and the accounts the vendor's transactions post to. What belongs in it is anything that would otherwise have to be agreed twice, which is why payment terms and the payable account belong there and a one-off delivery instruction does not. The test worth applying is whether the fact governs future transactions or describes a past one. Governing facts belong on the master record, transaction facts belong on the order or the bill, and the most common cause of a messy vendor master is the two being mixed until nobody trusts either.
How is a vendor's on-time delivery rate actually calculated, and what makes it trustworthy?
The trustworthy version is computed from documents the business already produces, not entered by anyone. It takes the vendor's order lines over a defined recent window, finds the goods receipts that completed against them, counts the quantity that arrived on or before the date promised on the line, and divides that by the quantity ordered. Three details decide whether the resulting number means anything. It should weight by quantity rather than by line, so one late pallet does not count the same as one late screw. It should compare against the promised date on the order rather than a date somebody re-entered later. And it should distinguish a vendor with no history from a vendor with a bad record, because a system that shows both as zero teaches its users to ignore the field.
Should vendor performance be scored, or measured?
Measured, and the distinction is not pedantic. A measurement is a quantity derived from records that exist for another reason, receipts against promised dates, invoiced price against agreed price, so it cannot be gamed without falsifying the underlying documents, and anyone can trace the number back to them. A score is a composite: several measures, weighted by somebody, rolled into one figure, often with a subjective component like responsiveness. Scores are more persuasive in a meeting and less defensible in an argument, because the conversation moves immediately to the weights. The practical approach is to measure what the transaction record can prove, keep the components visible, and treat any composite as a summary of those components rather than as the thing itself. Oracle sells the composite. NetSuite's procurement page offers, against poor supplier performance, "simple workflows and the vendor scorecard to effectively track vendor performance". A scorecard is genuinely useful when the inputs are agreed. The question to ask of any of them, ours included, is what the score is computed from and what happens to a supplier with no history yet.
What is a vendor pricelist and how does it decide which vendor gets the order?
A vendor pricelist is the set of agreed prices at which a specific supplier sells specific items to you, and the useful ones are scoped rather than global: each entry carries a minimum quantity, a unit of measure, a lead time and a validity window, so the same item can be priced differently at ten units and at a thousand, and an expired negotiation stops being offered without anyone remembering to remove it. Where the system also chooses the supplier, it does so by filtering the entries that qualify, right vendor availability, right quantity, current date, matching unit, and taking the cheapest of what is left after discounts, converted into one currency so that a euro quote and a dollar quote can be compared. The consequence worth understanding before relying on it is that the rule is arithmetic: it optimises price among qualifying rows, and it will not weigh a supplier's delivery record against a lower price unless you make it, which is why the performance measure and the pricelist are two separate things a buyer reads together.