Who Keeps Moving My Business Central Work Date?

 Let me paint you a picture.

It's Monday morning. You fire up Business Central. You've set your Work Date to March 31st because you're doing month-end closing. Life is good. Then your session times out, or you refresh the browser, or you log back in after lunch and... your Work Date has changed to a completely different date. Not today. Not the date you set. Some other date entirely.

You set it again. Next login? Gone. Again.

"I could've sworn I set that to March 31st." Yeah, you did. BC just decided you were wrong.

The Crime Scene

After some digging (and a fair amount of yelling at my monitor), I tracked the problem to Codeunit 40 – LogInManagement, specifically a little procedure called GetDefaultWorkDate().

Here's what it looks like out of the box:

Codeunit 40 - LogInManagement.al

procedure GetDefaultWorkDate(): Date

See those highlighted lines? That's the culprit. For demo companies (Cronus, I'm looking at you), this procedure grabs the last G/L Entry's Posting Date and uses it as your default Work Date. Every single login. Every session refresh.

So whatever the Posting Date is on that last G/L Entry, that's your new Work Date now. Could be a date from three months ago. Could be a date in the future. Doesn't matter what you had it set to before. BC will keep resetting it to that G/L Entry date every time you log in or your session restarts. Like a toddler who keeps unbuckling their seatbelt.

But Wait, I'm Using a Demo Company for Real Work

And here's where it actually starts to hurt. A lot of consultants, partners, and even small businesses run on demo/evaluation environments that still have the IsDemoCompany() flag set to true. Maybe they started with Cronus and built on top of it. Maybe they're testing in a sandbox. Whatever the reason, they end up in this exact trap.

You're trying to do month-end, quarter-end, year-end... and every time your session refreshes or you log back in, BC pulls a "new phone, who dis?" on your Work Date.

The Fix

The solution is to subscribe to the OnAfterLogin event from Codeunit 150 "System Initialization". This event fires right after login, so we can step in and force the Work Date to today's date before the user even sees a page. Like civilized software should.

WorkDateFix.Codeunit.al

codeunit 50100 WorkDateHandler

{

    [EventSubscriber(ObjectType::Codeunit,

        Codeunit::"System Initialization",

        'OnAfterLogin',

        '', false, false)]

    local procedure SetWorkDateOnLogin()

    begin

        // Override the G/L Entry-based Work Date

        // and just use today's date like a normal person.

        WorkDate(Today);

    end;

}

That's it. That's the whole fix.

Wrapping Up

If you've ever logged into a Cronus or demo company and wondered why your Work Date keeps changing to a date you didn't set, now you know. It's not you. It's GetDefaultWorkDate() pulling the Posting Date from the last G/L Entry every time your session initializes, with all the subtlety of a sledgehammer.

Drop that event subscriber into your extension, and you'll never have to fight this particular battle again.