What you describe is this set of relationships:
Customers----<Bookings>-----Items (---< means "one to many" )
If you want, you can put a portal to Bookings and a portal to Items on a customer layout. The portal to bookings will show each time an item has been booked and can include fields from items to provide additional detail. A portal to items will list each item that has been booked at least once.
I thought my diagram is Customers----<Bookings-----<Items
Or am I losing the plot?
You are correct. I misread your post. You can still put both portals as described, but now the portal to items will be a combined list derived from all bookings for that customer.
You might be interested in a pair of "master - detail" portals. With that design, you could click a row in the bookings portal to see only the items for the selected booking appear in the items portal.
Well I guess you are a mind reader then. Because that is exactly how the solution must work!
The actual project is for a magazine advertisement sales booking system. We are a small publishing house.
So the Customer orders advertisement(s) to appear in one or many month's edition(s) of a monthly magazine. For instance the Customer orders just one month, or a multi-month series of advertisements.
Therefore a booking will link to one, three, six, nine or twelve individual advertisement records. The advert records themselves will link to price lists, editorial feature, page position tables and lists ,etc etc.
So as you said, when a particular Booking in the bookings portal is selected it must only show those advertisement(s) that relate.