Obsoleted and “no longer invoked” events in v26 Business Central

Yeah – you read that right.

For quite a while (since version 19 (!) if I remember correctly (and if Grok is right )) Microsoft introduced a significant enhancement to the invoice posting process for sales, purchase and service documents.  The feature “Extensible Invoice Posting Engine” replaces the legacy “Invoice Post. Buffer” table and associated posting logic with a more flexible and extensible framework.  It should address limitations in the previous system – so that’s always good, I guess.

Now – I must confess – I’m no expert in the matter at all.  AT. ALL.  But it is a serious change of what we were used to – and of what we were using in our ISV and PTE apps!  Among them:

• A new invoice posting buffer table
• An Invoice Posting Interface
• Centralized event publishers

The latter – that’s what this post is about.

For a while, we knew it was coming, and v26 is the version where this feature became not a feature anymore, but the only reality.  So if you haven’t moved your code, if you didn’t implement the new extensibility points – well – I guess you better start crackin’.

Admittedly, Microsoft has been doing their upmost best for partners, developers, customers, .. to uptake this new approach.  It’s taken 7 releases .. and .. there was code that invoked when you enabled the feature, where the core part was to be found in function ‘CheckInvoicePostingEventSubscribers’.  The function was going to see if there were still subscribers on the old obsoleted events, and if so, you couldn’t enable the feature!

Sounds perfect, no? 

Well .. not completely, because it seems they were taking partner code into consideration .. but not PTE’s..

That’s the first warning

For reasons that are very much understandable (you can find a yammer thread here), Microsoft had to find some kind of solution for partners to grant the possibility for partners to be able to support customers on multiple versions (not every customer will be able to upgrade immediately) – with one version of their ISV solution. Because – we simply need to be able to support all customers: ones that are and are not yet upgraded.  If you didn’t know .. one of the still existing issues we have is that we can’t have more than one version of one solution in AppSource.  Which we want.  Which we need.  (trust me, they know – it’s just quite complicated … )

To be able to accommodate this – Microsoft chose to keep the events in place and not just remove them from the codebase. That means – the app will compile and be able to be published in v25 and v26. But .. at the same time, they chose to not invoke the events, most probably (this is my assumption) to avoid the invocation of the same code twice.

This is how that currently looks like in code:

I found 82 of such non-invoked events!

On top of that .. they seemed to have removed the code that I mentioned above, to check for existing subscribers on the old events.  I for sure can’t find any of it anymore in the v26 codebase!

Here’s the catch: Your code will compile (with warnings for obsolete events), will publish, but if it subscribes to these non-invoked events, it won’t work at runtime. This could lead to silent failures or unexpected behavior, putting you in for a rough ride!

For the life of me – I can’t get behind this solution.  I get the struggle, I get the wishes, I get the needs, and I get why it’s what it is.  But there are simply too many assumptions, too many unknowns .. and .. come on  .. events that are not even invoked?  I hope this is not going to be a new (best?) practice ..

Yes – I want my compiler to fail when events do not exist.
Yes – I want my upgrade to fail when I try to install an app that subscribes to non-existing events

I fear mainly for the unmaintained PTE’s. For the OnPrem environments. Because – if you have maintained all your apps, if you have upgraded to v25 – you’re good to go. But what if .. . This solution is based on so many assumptions – and it’s easy to make some worst case assumptions as well for this .. no?

Look .. I hope I’m very wrong in this!  Truly. I hope the reactions on this post will be: “waldo, you suck, you don’t know what you’re talking about .. whatever you say here is not worth any attention, we’re all good .. I would absolutely have no problem with that.

I even asked AI to proofread my post – and this is what it had to say:

I get the speculative claims – they are indeed speculative to say the least – these are my speculations .
And when I asked about the inaccuracies about the validation process, it basically said that “there is no clear evidence in Microsoft’s public documentation about it”. Well – also that is true .. . I got them by reading the codebase .. .

Anyway…

So what would you have done, waldo?

Well, I don’t know.  Haha.  I’m only here to complain, not to give solutions .

Foremost the obvious solution is being able to have multiple versions in AppSource.  Because if we would have been able to do that, you could simply have failed the new version, we could have solved it in vNext, while still being able to hotfix the previous.  THAT for me is the one and only solution.

I understand that was not possible (yet?) – but in the other case, I would still invoke the obsolete event – WITH the chance of double invoking the same event.  Think about it.  When ISV partners make the conscious choice to support both versions (pre and post feature), they can also manage the double invocation of the event, can they not?  (yes .. just say yes … ).

In my company – we simply do NOT make this feature an option .. we decide what features the customer uses, as we take responsibility over their implementation.  So we have been on the new stuff for quite a while now… . (Is it obvious I’m not a fan of the “Feature Management”-feature? )

Conclusion & some recommendations

Be mindful!  Use DevOps and fail your build pipelines when you are using obsoleted stuff.  Manage that!  Continuously! Prepare for the future .. continuously. Whether for PTE’s or ISV apps .. it’s important for all!

In this case – make sure when your customers go to v26, that you’re not subscribing to the non-invoked events!

Simple tip: we implemented pretty much the same check Microsoft did up until v25 for any customer that we upgrade to v26 with an upgrade codeunit .. for the entire PTE and ISV numberranges.  The upgrade will fail – and we’ll be happy it did . Just to be sure.

And may be – just make sure that you always upgrade to v25, and only then to v26 (especially true for OnPrem).  You kind of have to since it’s a “step release” (so you could say it automatically solves the problem (well – too many assumptions, sorry…)) – and while you’re in v25 – enable the feature while you’re at it .

And .. stay up-to-date. Also OnPrem – invest in upgrades as many times as possible.. .

Original Post https://www.waldo.be/2025/06/30/obsoleted-and-no-longer-invoked-events-in-v26-business-central/