You negotiated the price in March. In June somebody paid list.
The agreement was real: a year of the same component, a rate that took two calls to land, an email confirming it. What was never real is the path from that email to the person raising the order in June, who searched the vendor, took the price the system offered, and had no way of knowing a better one had been agreed. Nothing was overridden. The negotiated rate simply never became data.
What you get with purchase agreements
Purchase agreements that publish themselves. A blanket order records a vendor, a set of products, agreed prices and a validity window, and confirming it writes those prices into the vendor pricelist, so any buyer raising an order inside that window prices themselves off the agreement without being told it exists. Closing or cancelling the agreement removes those prices again. Each agreement line shows how much has already been ordered against it, summed from the confirmed orders that drew on it, so you can see what is left. The validity window is enforced rather than advisory, and choosing a vendor who already has an open agreement raises a warning naming it before a second one is written. A purchase template covers the other case: a reusable basket with no dates, for the order you raise every month.
Separately, the same capability handles competitive quoting. Several requests for quotation to different vendors can be grouped as alternatives to one another, then compared in a list scoped to the group and grouped by product, so the same item from each vendor sits together on one screen. Confirming one of them does not quietly abandon the others, it raises the still-open alternatives for a decision. And an agreement cannot be closed while any of its RFQs is unresolved.
Where purchase agreements comes from
It's already in Odoo, nothing to buy, no upgrade tier to reach, no extra fee per user, and the code runs on a deployment you own. It is not switched on by default; turning it on is an install, not a purchase. NetSuite sells this kind of blanket-order and contract handling inside a paid procurement tier; in Odoo it is already included, and that difference is the product.
One thing under this heading is genuinely not here, and it is what most people mean when they say "requisition". In Odoo the word describes the vendor side, a blanket order or a call for tender, not an employee raising an internal request for approval. There is no internal purchase-request feature in the base system, and no approval-routing app either. The spend control Odoo does offer is the two-level purchase order approval on a money threshold, which is a real control and a different one.
Whether a free add-on supplies the requestor-to-PO workflow is a question we have not yet answered, and we would rather say that than guess in either direction on a web page. What we will not do is tell you it is impossible: the add-on ecosystem around this product is large. If your buying process depends on internal requisition routing, put it on the table on the first call and we will go and look.
What is the difference between a purchase requisition and a purchase order?
A purchase requisition is an internal request to buy something; a purchase order is the external commitment to a vendor to buy it. The requisition travels inside the organisation, someone states what they need and why, and someone with budget authority approves or declines it, and it creates no obligation to anybody outside. The purchase order is what leaves the building: it names the vendor, the goods, the quantity, the agreed price and the delivery terms, and once accepted it is a commitment on both sides. One useful consequence of the distinction is that the two documents answer to different people. A requisition is a budget question, and a purchase order is a contract question, which is why systems that collapse them into one step tend to satisfy neither the department head nor the finance team.
What is a blanket purchase order and when is it worth having one?
A blanket purchase order is an agreement with a vendor covering repeated purchases over a period, the products, the agreed prices and the window during which those prices hold, against which individual orders are drawn as the need arises. It is worth having wherever the same thing is bought repeatedly from the same supplier and the negotiation is annual rather than transactional, because it moves the price discussion out of the ordering process entirely: the buyer raising the June order is not negotiating, they are drawing down. The mechanical benefit that matters most is that a blanket order can put the negotiated price where the buyer will encounter it, in the vendor's price list, so the agreement is enforced by being the default rather than by being remembered.
How should competing vendor quotes be compared without a spreadsheet?
By keeping the quotes as records in the system that will raise the order, and comparing them line by line rather than in total. Exporting three quotes into a spreadsheet produces a comparison that is correct on the day and disconnected from everything afterwards: the sheet does not know which quote was chosen, the chosen order does not know it was compared, and the two quotes that lost stay open until somebody remembers to close them. Grouping the quotes as alternatives to each other keeps all of that connected, the same product from each vendor can be shown together, the decision is recorded on the orders themselves, and confirming one raises the question of what happens to the others rather than leaving them to expire quietly. The line-by-line part matters because totals hide the case a buyer most needs to see, where one vendor is cheaper overall and more expensive on the two items that make up most of the volume.
What does "requisition" mean in an ERP, and why does it mean different things?
It means one of two genuinely different things, and which one depends on the system. In much of the procurement world a requisition is the internal request, an employee asks to buy something and an approval chain routes it, and the feature being sold is the routing. In some ERPs the same word names the vendor side: an agreement, a blanket order, or a call for tender inviting suppliers to quote against a stated requirement. Both are real and neither is a misuse of the word, which is why it is worth resolving early in any evaluation rather than assuming. The practical test is to ask which document the feature creates and who receives it: if the output is a request that goes to a manager, it is the internal sense; if the output is a document that goes to a supplier, it is the agreement sense. Oracle sells the internal sense as an addition. NetSuite's procurement page describes SuiteProcurement, where "buyers shop directly from a supplier's online store and check out" and the system "automatically creates a purchase request, initiates the approval process and automatically transmits the purchase order once approved". Worth knowing what you are buying, and whether the problem you have is catalogue purchasing or an approval that sticks.