| bc-version |
domain |
keywords |
technologies |
countries |
application-area |
|
|
architecture |
| workdate |
| session-setting |
| user-control |
| side-effect |
|
|
|
|
Application code must not change the WorkDate
Description
The work date is a per-user session setting the user controls from the
client (the date shown in the top-right corner, used to default posting
dates and date filters). Microsoft's own Business Central standard is that
application code must never call the WorkDate function to set a new
value. Doing so changes what the user sees and defaults to for the rest of
their session, as a side effect of running unrelated business logic — a
surprising, hard-to-trace behavior change the user never asked for and has
no visibility into.
This is a call-direction distinction: reading the current work date via
WorkDate (or WorkDate() with no argument) is fine and common — it is
only the assignment form, WorkDate(NewDate), that is the anti-pattern.
Best Practice
PostingDate := WorkDate();
Read the work date to default a value; never write to it.
Anti Pattern
WorkDate(CalcDate('<1D>', WorkDate()));
Setting the work date from within a codeunit, report, or page action
changes session state the user owns, for the duration of a call that has
nothing to do with the user's date preference. If a scenario genuinely
needs a specific date for a calculation, pass or compute that date as a
local variable — never repurpose the session's WorkDate.
