I would definitely break it down into small segments, each encapsulated in its own class. This helps immensly in debugging.
My preference is a diconnect of information:
GUI front end - communicates with
Class Data - holds data to be formatted by
Class Formatter - sends formatted data to
Class Print - or
Class PDF
However you do it, you should probably use a relational database (not an object database). That means getting your hands into SQL, which is fun and productive anyway. With a good database (I recommend MySQL) and some SQL, you're double-booking could disappear in lieu of some warnings.
For formatting you should probably look into GDI+. This would make it extremely easy to print to a PDF or plain paper. Another great option would be to buy a PDF library for .NET; the advantage being assurance of the PDF quality.
The GUI front-end I would design last, as data seems to change and wreck the original design (my products go through major face-lifts...). It should optimally be completely disconnected from the other classes except for references. This way, you can port the classes to other projects and debug them (not that your code would ever contain any bugs
) easier. Also, if you have password protection, a disconnect of the GUI from the Data would make it infinitly easier to secure.
Just my two cents here.