I don't have Visio, so I'll have to do without the diagrams
What info about the schools do you store? If it's more than the name (for example address, telephone, contactperson, etc), you really should make two tables, Schools and Classes, otherwise you'd have the same data stored in multiple rows.
Do try to keep database design and technical solutions (manual input) separated. You start by making an inventory of all user types of the system and what actions they will perform (use cases), then you identify the entities (which will become tables), their attributes and the relationships between them. Some normalization and you'll have a ERD (entity relationship diagram).
Once you have that, you can start thinking about how to implement the application.
A Purchasesdetails table, with a row for each item bought during that purchase. This will give you the opportunity to let people buy different books in one purchase.
See answer to point 1 above.
Ok. See also the answer to point 3 above.
As a technical solution you could provide an admin screen to input the lists manually by every single school. Or the possibility to import csv files that contain the lists. But that has nothing to do with the database design.
Take a look at cookies.
One by one? Really you don't mean that? Why not let them choose all the books they want to buy and put them in a shopping cart. That way they can make one purchase and type their contact info only once.
Ok. If the list is very long, you might want to add a search/filter function.
The last one might seem redundant (I'm sure that info is stored elsewhere as well (the Books table for example)), but prices might change over time, so to keep a history of the info at the time of purchase, I would store Price here as well.