[Bug]: All decimal fields behaves as amounts by default

[RSchoesterIdyn]

Describe the issue

A regular decimal field in our extension no longer accepts more decimal places than setup in the General Ledger Setup for Amounts. This used to work in previous BC versions, so it's a breaking change.

This is how the field is defined in our extension:

(no decimal places setup and no AutoFormatType)

This is the error we get when we try to enter more positions than the Amount Unit Precision allows in the General Ledger Setup:

When I change the Amount Decimal Places to 2:5 in the General Ledger Setup (and I refresh the session), then the same value is accepted.

Expected behavior

The Decimal Places for Amounts and Unit Amounts should only be applied to decimal fields with a corresponding AutoFormatType.

Steps to reproduce

This issue seems to apply to all our decimal fields in all our extensions.
So, reproduction should be quite straightforward:

1. Create a new decimal field in an extension.
   This decimal field should not have any properties except a caption and a dataclassification.
2. Add the decimal field to a page.
   Set the ApplicationArea and a Tooltip.
3. Publish the extension
4. Verify that the Amount Decimal Places are set to 2:2 in the General Ledger Setup.
5. Enter a decimal with more than 2 decimal places (0.0001).

Additional context

We do have a workaround, but it requires that we explicitly set the decimal places for the decimal fields.

We have seen this behavior in Version: NL Business Central 23.1 (Platform 23.0.13763.0 + Application 23.1.13431.13546)
But also in the latest builds of BC22

There is also something off with the error message as it doesn't give the option to copy the call stack, which is the new behavior in BC23.

[JesperSchulz]

Nice catch! Let's get the issue to a team who will fix and backport it, as this repo only is for extensibility related issues in the upcoming release. We suggest that you open a support case or file a bug in Collaborate, to ensure that all Business Central users benefit from your catch as soon as possible.

To open a support case, you can:

• Open a support request to CSS through the PartnerSource portal
• Contact your Service Account Manager (SAM) in your local subsidiary to understand what is included in your contract as of support incident and PAH (Partner Advisory Hours). Your SAM might also direct you "step by step" how to open a support request or how to get credentials, if this is the first time for you or your company

If you file the bug in Collaborate, remember to include steps to reproduce the issue, and the Business Central build number and country version you're using. Here's a link to Collaborate: https://developer.microsoft.com/en-us/dashboard/collaborate/engagements/1173/feedback/wits/Bugs/create.

Thanks for reporting the issue.

[dannoe]

@RSchoesterIdyn Is this an NL specific change? I tested this with older BC versions and even in old NAV and couldn't see any difference. If there are no explicit properties set on the table field, the settings from the G/L setup will be used.

[RSchoesterIdyn]

@RSchoesterIdyn Is this an NL specific change? I tested this with older BC versions and even in old NAV and couldn't see any difference. If there are no explicit properties set on the table field, the settings from the G/L setup will be used.

I don't think it's NL specific, most likely a platform issue.

[dannoe]

I think you have misunderstood my post:

The behavior in BC23 is the same as in BC22.5, BC22.3 and even NAV14.
All these versions use the G/L setup settings for decimal fields if no DecimalPlaces or AutoFormatType/AutoFormatExpression is specified.

Maybe you overwrote the setting from the G/L setup with EventSubscribers in the past and the subscriber somehow got lost in your extension? Or you uninstalled another extension that changed this behavior.