The entered date is out of fiscal year (oh, no sir, it's not!)

******************************************************************************************************************************************************
Longer Subject:  The entered date is out of fiscal year (oh, no sir, it's not!) so you're Journal Entry ain't gonna happen (wanna bet?)
******************************************************************************************************************************************************
supportingDocs: https://imgflip.com/i/79hs43 (Images probably too small to be useful to anyone).

I hit another anomaly and  It's a bit of an issue.  An accountant needs to be unfettered when setting up a new company.  That person might be working on 2021 in 2023 - trying to enter a T/B to carry forward, etc.  Lots of reasons.  I can't apparently provide attachments to this post, but I have a 2021 fiscal year selected, and set up in the Company as active.  Under fiscal years it is also set up, and it should be good to go.  Now mind you, I'm doing this work in 2023, but FOR 2021.  This is real world stuff.  So I wanted to establish in 2021 accounts the "activity" - - profit and loss, with an entry to would encapsulate all activity for 2021.  Then the plan was to close this out, and roll into 2022 and basically do the same thing.  Even though 2021 was the ONLY active year set up, FA would not let me make the entry.    The offending code is found in gl_journal.php as follows:

// Would not let me post a journal entry in 2021, even though it was all set up for that.
        elseif (!is_date_in_fiscalyear($_POST['date_']))
        {
              display_error(_("The entered date is out of fiscal year or is closed for further data entry."));
              set_focus('date_');
              $input_error = 1;
        }
This, as I'm sure you know, calls the date_functions.inc and keys off of this code:

function is_date_in_fiscalyear($date, $convert=false)
{
        global $path_to_root;
        include_once($path_to_root . "/admin/db/fiscalyears_db.inc");

        if ($convert)
                $date2 = sql2date($date);
        else
                $date2 = $date;

        if (is_date_closed($date2))
                return 0;

        if (user_check_access('SA_MULTIFISCALYEARS')) // allow all open years for this one
                return is_date_in_fiscalyears($date2, false);

        $myrow = get_current_fiscalyear();
        $begin = sql2date($myrow['begin']);
        $end = sql2date($myrow['end']);
        if (date1_greater_date2($begin, $date2) || date1_greater_date2($date2, $end))
        {
                return 0;
        }
        return 1;
}

Not being able to post a 2021 entry to basically mimic the activity, albeit in summary, would render FA useless to me.  To get around this I simply commented out the function (last one I presented above) and ran the journal entry, and of course it worked fine once the digital hand-cuffs were removed.

My question is WHY DID THIS HAPPEN?  Trust me when I tell you everything in FA pointed to 2021 as the active year.  I have screen shots to back this up, but again I can't share them here.

Anyway, I just copy the original file (e.g., gl_journal.php -> gl_journal_original.php) and then make modifications to the gl_journal.php file.  Like I said, to comment out the handcuffs.  Once completed I just copy the original php code back into the directory.  This is a PITA so I'm hoping there is a reason for this.  If not, then it's definitely a bug.

Thanks.
Mac