Bug: Standard fields of type Code don't sort properly when you use number codes

(2) Share

Report

Posted on by JFuentes

Seems that in BC SaaS v20.0.ES standard fields of type Code don't sort properly when you use number codes.

We have needed to cut the numbering of the Sales Orders "No." and this is the result now when sorting by the PK the Sales Orders List.

I think this is a global standard Bug...

Could someone report it to Microsoft?

NOTE - The chosen numbering has not depended on me and it is too late to change it...

All responses (6)

Sort by

IB-29041624-0 1,191 Moderator on at

Like (0)

Report
Copy link

Link copied!

Hi,

This is not a bug. This is the designed behavior of a code field.

A code field is basically a text field and numeric values entered into a code field is sorted as they would be text values.

This is why you see this sorting behavior for a code field.

Letters entered into a code field is always turned into capital letters. That is also a behavior of a code field.
JFuentes 4 on at

Like (0)

Report
Copy link

Link copied!

Hi NorthW ,

I'm sorry to disagree with your opinion about this is not a Bug of standard BC...

If you know old Navision versions running over "native" database engine, Code fields sort like numbers when all registers have numbers in this fields... by desing, not only convert to capital letters.

When Navision started support running over MS SQL Server database engine, on migration projects this was an issue that MS solved adding the "SQL Data Type" property to fields and saying developers that we should set the Variant value to this property of all the standard and non-standard fields we needed...

With Navison and (and BC OnPrem) developers can modify this property over standard fields, but with BC SaaS infraestructure this is not possible, so I think Microsoft should set "SQL Data Type" = Variant by default in all standard Code fields to retrieve the full native behaviour of Code datatype fields or allow customize this property in tableextension objects.
IB-29041624-0 1,191 Moderator on at

Like (0)

Report
Copy link

Link copied!

I think you have two options.

Either submit it as a product idea on https://experience.dynamics.com/ideas/ or if you really think it is a bug you should report it through your CSP partner.
YUN ZHU 103,712 Super User 2026 Season 2 on at

Like (0)

Report
Copy link

Link copied!

Hi, as Inge said, this is not a bug.

But this is really a problem, I understand your idea very well. I have experienced that customer want to move line up and down before, because normal sorting cannot satisfy them..

This may not be the same page, but in this case, you can create a new field and reorder by the new field.....Of course this is cumbersome, and developers are generally reluctant to do it.

A simple example: https://yzhums.com/13671/

Hope this helps.

Thanks.

ZHU
JFuentes 4 on at

Like (0)

Report
Copy link

Link copied!

Thanks yzhums ,

I think your solution is very interesting, but is not valid for this scenario because every new sales order should be sorted before the existing ones that were created with one more digit in its primary key...
Assisted by AI

Grigorios Mavrogeorgis 3,708 Super User 2026 Season 2 on at

Like (0)

Report
Copy link

Link copied!

Hi, this is not a bug. The No. field is Code, and Code is text, so it sorts character by character, not as a number. 200195 lands before 20200 because on the third character you have 0 against 2.
As long as every number has the same amount of digits it sorts the way people expect, that's why the standard series keep a fixed pattern.
For the ones already created there's not much, you can't renumber posted documents. If the sorting really hurts users, a small extension with an integer field filled from the No. and the list sorted on that would work. Not pretty, but it does the job.
Glad to help - follow up if anything is unclear.
► If this solved it, marking it verified helps others too.
Regards,
Grigorios Mavrogeorgis
Business Central Consultant & AL Developer
Work: Gmsoft Limited
Blog: insidebusinesscentral
LinkedIn: linkedin.com/in/gregorymavrogeorgis