Allow Posting From/To DateFormula: No More Monthly Date Updates from Business Central v28

 Business Central 28 introduces DateFormula-based posting period fields that automatically calculate your allowed posting range. Here's what changed, how it works alongside the existing fields, and what the code actually does.

The Problem Everyone Knows

If you've worked with Business Central for any length of time, you know the drill. Every month (or every period close), someone has to go into General Ledger Setup and manually update the Allow Posting From and Allow Posting To date fields. Same thing on the User Setup page for individual users who need different posting windows.

 

Miss it, and users can't post. Update it late, and someone might accidentally post into a closed period. It's a small administrative task, but it adds up, and it's surprisingly easy to forget.

What's New in BC28

With Business Central 2026 Release Wave 1 (BC28), Microsoft has added two new fields to both the General Ledger Setup table (Table 98) and the User Setup table:

New Field	Field No.	Type	What It Does
Allow Posting From DateFormula	205	DateFormula	Calculates the start of the allowed posting range dynamically
Allow Posting To DateFormula	206	DateFormula	Calculates the end of the allowed posting range dynamically

These fields use the standard DateFormula data type, the same one you see in payment terms, lead time calculations, and other places across Business Central. The system takes the work date, applies your formula, and determines the allowed posting window automatically.

 

No more monthly manual updates. Set the formula once, and the posting window moves forward on its own.

The Key Rule: DateFormula and Date Fields Are Mutually Exclusive

This is the most important thing to understand about this feature. You can use either the static Date fields or the new DateFormula fields, but not both at the same time. The code enforces this automatically.

How the mutual exclusivity works

If you set a DateFormula value, the system automatically clears the corresponding static Date field (sets it to 0D). And if you set a static Date value, the system automatically clears the corresponding DateFormula field (evaluates it to an empty string).

When you enter a DateFormula (say <-CM>), the trigger checks if the formula is not empty. If it has a value that clears the static date field to blank. Then it validates the date range.

Same thing in reverse. When you enter a specific date (say 03/01/2026), the trigger checks if the new date is not blank. If it has a value, it clears the DateFormula field by evaluating it to an empty string. Clean and simple.

The same pattern applies to the "Allow Posting To" (Field 3) and "Allow Posting To DateFormula" (Field 206) pair. The logic is identical.

 

Bottom line: You don't need to worry about conflicts between the old and new fields. The system handles it. Fill in one, and the other gets cleared automatically. They can coexist on the same page, but only one of each pair will hold a value at any given time.

Practical Example: Setting It Up

Scenario: Monthly Posting Window

Your company wants users to only post within the current month. Previously, you'd set Allow Posting From = 03/01/2026 and Allow Posting To = 03/31/2026 in General Ledger Setup, then remember to change both fields when April starts.

 

Field	Value	Meaning
Allow Posting From DateFormula	<-CM>	Beginning of the current month
Allow Posting To DateFormula	<CM>	End of the current month

With today's date being March 13, 2026, the system calculates:

Allow Posting From = March 1, 2026 (CalcDate of <-CM> from today)

Allow Posting To = March 31, 2026 (CalcDate of <CM> from today)

When April starts, the window automatically becomes April 1 through April 30. No one needs to touch it.

What Happens When You Post Outside the Range?

The error behavior is exactly the same as before. Whether the posting range comes from a static date or a calculated DateFormula, if the posting date on your document falls outside that range, you get the familiar error.

Error

"Posting Date is not within your range of allowed posting dates ...."

Note: Same fields available on User Setup.

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. 

Create Purchase Orders from Drop Shipments

If you have worked with drop shipments in Business Central, you know the process has always been a bit... indirect. You would create a sales order, mark lines for drop shipment, and then separately create a purchase order and use the Get Sales Orders action to pull those lines in. It worked, but it was not exactly smooth, especially when you were juggling multiple orders.

With Business Central 2026 Release Wave 1 (BC28), Microsoft has simplified this workflow. You can now create purchase orders directly from the sales order itself using the Create Purchase Orders action. On top of that, drop shipment lines are now included in the Order Planning page when you calculate plans, and the Planning Worksheet page gets a dedicated Drop Shipment action group.

What Exactly Changed?

1. Create Purchase Orders Directly from Sales Orders

Previously, to create a purchase order for a drop shipment, you had to leave the sales order, go to the purchase side, and manually pull in the sales lines. Now there is a Create Purchase Orders action right on the sales order. Business Central looks at your drop shipment lines, figures out the vendor from the Item Card or Stockkeeping Unit Card, and suggests the purchase order lines for you. You review, tweak if needed, and you are done. 

2. Drop Shipments Included in Order Planning

The Order Planning page now considers drop shipment lines when you run Calculate Plan. Before this update, drop shipment demand was essentially invisible to the planning engine. Now it shows up alongside your other demand, which gives you a more complete picture of what you need to order and when.

3. New Drop Shipment Actions in Planning Worksheet

The Planning Worksheet page now includes a dedicated Drop Shipment action group with Get Sales Orders and Sales Orders actions. This mirrors what the requisition worksheet already had, bringing consistency across the planning tools.

Tip: Vendor Determination Business Central picks the vendor from the Item Card's Vendor No. field first. If you use Stockkeeping Units (SKUs), the vendor configured on the SKU for that location takes priority. You can always override it on the Create Purchase Orders page before confirming.

Before vs. After: Quick Comparison

 

Area	Before (BC27 and earlier)	After (BC28)
Creating POs from Sales Orders	Create PO separately, then use Get Sales Orders from the purchase order	Create Purchase Orders action directly on the sales order
Order Planning	Drop shipment lines not included in Calculate Plan	Drop shipment lines are included when calculating plans
Planning Worksheet	No dedicated drop shipment actions; only available in requisition worksheet	New Drop Shipment action group with Get Sales Orders and Sales Orders actions

Define Item Attributes for Item Variants

The public preview for Dynamics 365 Business Central 2026 release wave 1 (BC28) is now available, and there’s a feature in this release that many of us in the BC community have been waiting for. You can now define item attributes at the item variant level. It sounds simple, but if you’ve ever worked with variants in a real-world scenario, you know how much this changes things.

Let me walk you through what this feature does, how it works, and why it matters.

The Problem This Solves

Item variants have been a great way to keep your product list manageable in Business Central. Instead of creating a separate item for every color, size, or material variation, you set up one item and define the variants underneath it. A t-shirt in five colors? One item, five variants. Much cleaner than five separate item cards.

But here’s where it used to fall short: item attributes. Until now, attributes were only defined at the item level. So if your base t-shirt had an attribute of “Color: Blue,” all your variants inherited that same value. The red variant? Also said “Blue.” Not ideal.

You either had to live with inaccurate attribute data on your variants, or you gave up on variants entirely and created separate items just so each one could have the right attribute values. Neither option was great.

What’s New in BC28

With this release, you can assign attribute values that reflect the specific variant at the item variant level. Variants still inherit attributes from the parent item, but you can now adjust or remove those inherited values when a variant needs different information.

Here’s what that looks like in practice:

Key Capabilities: •      Assign attribute values directly to individual item variants •      Variants inherit attributes from the parent item automatically •      Adjust or remove inherited values per variant as needed •      New Item Variant Attribute Values page accessible from the Variants List or Variant Card •      New Update Variant Attributes action on the Item Card to force sync from item to variants

How It Works

Attribute Inheritance

When you add a new variant to an item, the attributes defined for that item automatically transfer to the variant. This is the inheritance part. If you’ve already set up attributes like Material, Weight, or Color on the parent item, your new variant gets all of those right away.

One thing to note: if no attributes are defined on the parent item, the variants will also be empty. The inheritance only works when there’s something to inherit.

Editing Variant-Specific Attributes

Once the attributes are inherited, you can open the new Item Variant Attribute Values page to review and edit them. You can get to this page from either the Item Variants List or the Item Variant Card. From there, you update or delete the inherited values so each variant shows the correct details.

So back to our t-shirt example: your parent item might have Color set to “Blue” (the default). When you create the “Red” variant, it inherits “Blue,” but you can immediately go in and change it to “Red.” Simple, clean, accurate.

Syncing Attributes with Update Variant Attributes

There’s also a new Update Variant Attributes action available directly from the Item Card. This lets you force a sync of attributes from the item down to all its variants. It’s useful when you’ve added or changed attributes on the parent item and want to push those changes out to existing variants without going through them one by one.

Create Purchase Quotes for Contacts in Business Central

The public preview for Dynamics 365 Business Central 2026 release wave 1 (BC28) is now available, and there are some really useful features in this update. One that caught my attention is the ability to create purchase quotes for contacts that aren't yet associated with a vendor. If you've worked in purchasing, you know the friction here. Let me walk you through it.

The Problem This Solves

Until now, if you wanted to create a purchase quote in Business Central, you needed to have a vendor record already set up. That sounds reasonable in theory, but in practice it creates unnecessary work. Think about it: you're exploring a potential purchase from a new supplier. You're not even sure the deal will go through. But before you can even draft a quote, you have to go create a full vendor record. That's wasted effort if the purchase never materializes.

How It Works

The concept is straightforward. You can now create a purchase quote and assign it to a contact that isn't linked to any vendor. Business Central lets you fill in the quote details, add your lines, and work with the document just like you normally would. The key difference is that you don't need a vendor number to get started.

Here's the step-by-step process:

1.    Create a Purchase Quote and select a contact that isn't linked to a vendor. The Purchase Quote will be created without a Vendor No., and that's perfectly fine at this stage.

2.    Choose a vendor template if multiple templates are available. Business Central selects the template based on criteria like territory code, country/region code, and contact type. 

3.    Enter the quote details as you normally would. Add your lines, quantities, prices, and any other information you need.

4.    Release the quote or convert it to an order. At this point, Business Central automatically creates the vendor record using the template. The vendor is created only when you actually need it.