Business Central Updates and Compatibility

Business Central gets a new major version twice a year, and Microsoft removes or replaces standard objects and fields along the way. This page explains what that means for extensions generated by Simple Object Designer, how to prepare for an update, and how to resolve the errors and emails that show up around one.

The One Rule: Update SOD, Then Republish

Before any Business Central version update:

Update Simple Object Designer to the latest version from AppSource
Publish your app again from SOD
Then run or reschedule the Business Central update

Installing a new SOD version is not enough on its own. The extension in your environment was generated by the old SOD version and stays exactly as it was until you republish. Almost every "I updated SOD and the error is still there" case comes down to a missing republish.

How Compatibility Works

SOD is kept compatible with new Business Central major versions as they are released, and compatibility updates are published to AppSource.

When a new BC major version reaches preview, work begins on making SOD generate code compatible with it. Compatibility arrives in a specific SOD version on AppSource. (For example, SOD 12.0.0.604 produces a BC27-compatible app.)
Because that work starts after the BC preview appears, compatibility with a brand-new BC major version can lag slightly behind the preview release.

SOD generates references to standard Business Central objects. When Microsoft removes one of those objects in a new version, an app generated by an older SOD refers to something that no longer exists, and validation fails. Example: in BC 28 the "Document Attachment Factbox" page was removed and replaced by "Document Attachment List Factbox". The fix is always the same — update SOD, republish — rather than disabling features by hand.

Compatibility Emails from Microsoft

Microsoft sends automated emails titled "Modify your extension so it's compatible with the version {version}" about extensions in your environment. They arrive for SOD-generated extensions and for any other custom app alike. Not all of them mean the same thing.

Known false positives

AVS0005. An email may report Error AVS0005: A package with publisher 'Microsoft', name 'System', and a version compatible with 25.2.0.0 could not be found. This is a false positive from Microsoft's automated testing, sent broadly to many publishers. No change to your extension is needed — ignore it.
v27 emails (version 27.0.31853.0). Microsoft's cloud-based compatibility testing broke and produced incorrect incompatibility reports for extensions of all kinds. Those emails could be safely ignored and deleted while Microsoft fixed the system.

Treat the v27 case as a historical example, not a standing rule: verify the current status rather than assuming every future email of that shape is a false positive.

Genuine warnings

v26 emails were valid. Many SOD users received real warnings caused by APIs exposing fields that had become obsolete. Those fields must be removed from the affected API endpoints, and the extension republished, before the environment can be upgraded.

The distinguishing question is whether the error names a specific field or object in your app. If it does, it needs fixing; if it complains about Microsoft's own System package being unavailable, it is noise.

AL0185: Codeunit 'NoSeriesManagement' is missing

Symptom: the Business Central environment update (for example to BC v27) fails with:

Error AL0185: Codeunit 'NoSeriesManagement' is missing

Cause: the published app was generated by a SOD version that references the old codeunit. A fix was introduced in SOD 12.0.0.604, but being on that exact version is not necessarily sufficient.

Resolution:

Update SOD to the latest available version
Republish your app
Reschedule the Business Central update

AL0433: Field is removed

Symptom: an email or validation error such as:

Error AL0433: Field '<FieldName>' is removed. Reason: Use the field '<NewFieldName>' instead. Tag: <version>.

This happens when Microsoft removes or renames a standard field that one of your SOD-generated APIs exposes.

Extensions generated by SOD are tenant extensions living in your own environment; the AL source is not owned or hosted by hougaard.com. The fix is done entirely inside SOD — you never need to edit AL by hand.

Resolution:

Open Expose data as web services in SOD
Open the affected object (for example the Item API)
Scroll the field list to find the removed field and remove it — standard and less common fields often sit near the end of the list
Publish the API again

The environment can then be upgraded.

Worked example: Scheduled Need (Qty.) on the Item table was removed in BC 28.0 and replaced by Qty. on Component Lines. Removing Scheduled Need (Qty.) from the Item API and republishing resolved it.

Publishing Errors After a Business Central Update

After a platform update — especially a major version such as BC 28.0 — Microsoft changes, removes, or obsoletes fields in standard tables. SOD's symbol cache may still describe the old fields, so generated API pages fail to compile.

The error dialog often includes the hint: "Normally these errors should never occur. Most errors are due to symbols not being up to date." That hint is usually right.

Typical field changes behind these errors:

Field	Table	What changed
`Scheduled Need (Qty.)`	Item	Removed, replaced by `Qty. on Component Lines`
`Shpfy Risk Level`	Sales Header	No longer imported
`IRS 1099 Code`	Vendor	Moved to the IRS Forms App
`IDPCOS Dummy Exclude Stats`	Item	Now inaccessible due to protection level

Step 1 — Refresh symbols, clearing the cache

Open the SOD Setup page
Click Download Symbols
Answer Yes when prompted to clear the cache — this is required, not optional. Refreshing without clearing leaves stale field references behind.
Authenticate when prompted and let it finish; on large environments this takes a few minutes

Step 2 — Fix each affected endpoint

Open every API endpoint named in the errors (Item, Sales Header, Stockkeeping Unit, Vendor, …) and remove or replace the obsolete fields. Then publish.

Step 3 — If the errors persist

If the identical errors remain after a symbol refresh with cache clearing, the known workaround is to delete the affected API endpoint and recreate it.

This is a manual workaround, and it may need repeating whenever a feature update adds or removes fields. There is no automatic remedy today.

APIs Consumed Elsewhere May Also Need Attention

An update that changes your published API will affect its consumers. After a BC update:

Re-check Power BI, Power Automate and Dataverse connections against the API — see Consuming APIs
Re-download symbols before assuming a query or API defect — see Symbol Troubleshooting

Warnings You Can Safely Ignore

Generated code may produce "marked for removal" warnings about deprecated Business Central objects, such as:

Codeunit 'Sales Price Calc. Mgt.' is marked for removal. Reason: Replaced by the new implementation (V16) of price calculation. Tag: 16.0.
Table 'Sales Price' is marked for removal. Reason: Replaced by the new implementation (V16) of price calculation: table Price List Line. Tag: 16.0.

These are fine. The old price calculation system is still present and active in Business Central, and the warnings do not block anything.

Known Runtime Compatibility Issue

A referenced module built with runtime reference version 14.3 cannot be loaded by a compiler at version 14.0, which causes a publishing failure. This is being addressed by Hougaard. If you hit this specific version mismatch, check for an updated SOD release rather than modifying your own app.

When to Send Diagnostics to Support

Some package validation failures are not self-explanatory, for example:

AL0185: Query '<QueryName>' is missing
PTE0004: Table <ID> '<TableName>' is missing a matching permission set

These can appear even for a feature that published successfully before, so "it used to work" is not evidence the configuration is intact. Rather than guessing:

Use Download Source to produce a ZIP of the generated AL source
Email the ZIP to support@hougaard.com for review