This can all be done, but it's difficult to go into detail without more detailed information from you.
Are the seasons strictly identified by the month of the year? Is there event the slightest chance that a "season" might need to be defined to be a different set of months in the future?
An unstored calculation field can use the Month function to extract the month from the reservation date and use it either as a match field in a relationship or in a case function to return the text that you want. (Using it via a relationship makes it simple to change the range of dates that define a given season from year to year...)
And your discount calculation is definitely possible, but how you implement it will depend on what tables and relationships you have set up to manage the reservations made for each apartment.
Yes the seasons are identified by the month of the year because I don´t know how to define them in the future. I have the next relations but if I make the relation between start date, end date (in season) and date check in (in booking), the solution doesn´t work like I want. I want that when I choose the date check in automatically appear the name of the season but for example I can have High Season Maderas and High Season Santiago, so also I need to chose the name of the Condo to acquire the season and its rates.
Month ( dateField ) will return the number representing the month.
This can be placed in a calculation field that is used as a match field to a table of seasons.
A second match field can identify the condo and thus the two in combination can be used to match to the "season" record for the specified month falling in a range of month values for that season.
The relationship might look something like this:
Reservations::cMonth > Seasons::MonthStart AND
Rservations::cMonth < Seasons::MonthEnd AND
Reservations::_fkRentalUnitID = Seasons::_rkRentalUnitID