The PDF could also be generated dynamically from the content of the database (see also FPDF for an alternative). It depends on how your customers use the document whether staying with PDF is worthwhile or if they're fine with just a web page (possibly with @media CSS for print output).
Constructing the code to dynamically generate the PDF would involve somewhat more work than a web page, of course.
But the database is crucial, since you say you need to separate the task of maintaining the price list from the task of rendering it; the db bridges those tasks. It probably doesn't need the full DBMS treatment; if your editor knows Excel then exporting a bunch of CSV files. Or, using something like PHPSpreadsheet (that's just the first active project on the subject I found in a search, not an endorsement), read the Excel file directly.
Be aware that an Excel>PDF>display process on every request would be significantly slower than just a link to a static document. Most uses of these libraries would be for offline conversion/generation, not real time. So it would be an application the editor would run once when the spreadsheet has been updated, and the PDF (or HTML page) generated and put on the site. At which point I wonder if Excel can be coerced (actually I'm pretty sure it can) into producing a document that looks a lot like what you already have. Because then the editor can just edit the spreadsheet and export the PDF straight from Excel.
Hm...
pbismad As a note, by using a .pdf document, that page is not directly searchable in the browser (the browser listed x number of results, but it wasn't scrolling and showing what was expected.
It was working for me; mind you, I had the page focused on the PDF.
pbismad Another advantage of just displaying this as a html document is, you can have letter based navigation, so someone can just jump to the section starting with specific variety names.
PDFs can also have bookmarks and links.