>> The very first thing that I did is to create a table that will store these Descriptive Labels along with the Actual Start and End Dates for that period. <<
This was a good start, except you didn't actually create a table of all! By definition, a table must have a key. Your DDL had none. So it's basically a deck of punch cards.. Then you put in the physical count of record insertions, also known as identity in the local SQL Server dialect. It is both meaningless, physical and redundant; we hate all these things in RDBMS. You also have no constraints on the two timestamps that form the interval. SQL Server currently has no interval data type, so you have to use a pair but you need to put constraints on the pair to protect ordering and uniqueness. I also have the feeling that your use of a fifty character name was not the result of careful planning, or the use of check constraints to make sure the string is always valid. Why don't you sit down and actually design the encoding scheme for those. Names?
We have a new temporal data type for a date, so there's no need to stay stuck in the original Sybase/SQL Server proprietary data types.
CREATE TABLE TimePeriods
(period_name VARCHAR(35) NOT NULL PRIMARY KEY,
period_start_date DATE NOT NULL,
period_end_date DATE NOT NULL,
CHECK(period_start_date < period_end_date));
There are some other constraints. You can add to guarantee that no two intervals overlap, that you have complete coverage of the calendar, etc. that might be a little advanced for now.
>> Once the table was created, I quickly created a Stored Procedure that will populate values into this table so that our base for the reports will be ready. <<
Instead of writing a procedure, I found it's usually better to get a spreadsheet from the accounting department and make sure that the dates I'm using will match the ones the accounting department is using. Since this is a one-shot, it's just as easy to edit it as text.
Your procedure code doesn't look like SQL at all. It's very procedural, like BASIC or Fortran. But SQL is a declarative language designed for data not for computation. Determining the relative positions like "today", "yesterday" and so forth should not be done in the database layer. It belongs in the presentation layer. Also, for future reference, putting metadata affixes like "usp_" is considered bad programming. The valid data model the data element names should describe what the data element is, not how it's used or implemented in the system. I see you are still using the original Sybase GETDATE() and not the ANSI/ISO standard SQL uses current_timestamp. It will still work, but does not port and it makes you look very very old fashion. Also, ANSI/ISO standard SQL uses only the "yyyy-mm-dd"; since this is the most common ISO standard. After the metric system, this is the most common standard on earth. Experienced programmers will tend to use it instead of some local dialect like you are.
Finally, your intervals, overlap in your print out. This is ambiguous and will result in double counting at the borders. You will now have to write slow code and be very, very careful. It also violates the standard definition of a temporal interval.
Please post DDL and follow ANSI/ISO standards when asking for help.