[Bug]: A regression was introduced in codeunit 7002 "Price Calculation - V16" in procedure PickBestLine.

[AlexCeg]

Describe the issue

A regression was introduced with BC27.5 in codeunit 7002 "Price Calculation - V16" in procedure PickBestLine.

With the recent change, the logic for AmountType::Discount no longer considers IsImprovedLine and IsDegradedLine, which previously ensured that more specific price list lines (e.g. with Variant Code or Currency Code) were preferred over less specific ones.

As a result, more specific discounts are no longer selected correctly.

---

🔁 Regression

Yes – this is a regression compared to the previous implementation.

Previous behavior

The selection logic applied both:

• IsImprovedLine
• IsDegradedLine
• IsBetterLine

This ensured that:

• More specific lines override generic ones
• Best discount is chosen within the correct specificity level

Current behavior

For AmountType::Discount, only IsBetterLine is evaluated:

if AmountType = AmountType::Discount then begin
    if IsBetterLine(PriceListLine, AmountType, BestPriceListLine) then begin
        BestPriceListLine := PriceListLine;
        FoundBestLine := true;
    end;
end;

This skips specificity handling entirely.

Expected behavior

❗ Expected Behavior

More specific discount lines (e.g. with Variant Code, Currency Code, or other filters) should be prioritized over less specific ones, even if the discount percentage is equal or slightly lower.

❌ Actual Behavior

Generic discount lines can override more specific ones because specificity is no longer evaluated.

This leads to:

• Incorrect discount selection
• Loss of business logic consistency
• Breaking changes for existing implementations relying on specificity

Steps to reproduce

🔬 Steps to Reproduce

1. Create two price list lines:

   • Line A: Generic (no Variant Code), Discount = 10%
   • Line B: Specific (with Variant Code), Discount = 20% (or even slightly lower)

2. Trigger price calculation

3. Observe that:

   • Discount 20% is selected
   • The generic line is selected instead of the specific one

Additional context

We have extended the pricing logic by introducing additional custom fields that increase the specificity of price list lines.

Before this change, these fields worked correctly in combination with the standard specificity logic (IsImprovedLine / IsDegradedLine). After the change, this logic is bypassed for discounts, which means our extensions no longer behave as intended.

This issue therefore affects all of our customers, as the discount calculation no longer respects specificity across both standard and custom fields. The result is systematically incorrect discount determination in real business scenarios.

I will provide a fix for a bug

• I will provide a fix for a bug

[JesperSchulz]

@AleksandricMarko, could you please triage this one?

[AleksandricMarko]

Hello @AlexCeg
Just to double check, related to your repro steps:

• should generic one be with discount 20%?

Also, i am curious what is the business need to have smaller discount on specific scenarios?

[AlexCeg]

Hello @AleksandricMarko,
I think I wrote it a bit unclear:

Price List Line 1: Item A, Variant empty, Discount 20 %
Price List Line 2: Item A, Variant X, Discount 10 %

When I enter Item A and Variant X in a sales order, the 20 % is taken even if price list line 2 defines a more specific discount because of the filled variant.

[AleksandricMarko]

AB#626497

[AlexCeg]

Hello @AleksandricMarko,
above I said that I will provide a fix for this bug. I just want to clarify, if should really do this or if you are tackling this. My solution would be to just remove this code (green background), that was added:

[AleksandricMarko]

Original code change is introduced as a fix to the scenario where price for variant did not include item discount

Variant Any line (0%) processed FIRST, then item discount (10%)

0% variant line → IsBetterLine: 0 > 0 = false → skipped entirely
10% item discount → IsImprovedLine = false, IsDegradedLine = false → enters block, no clear → IsBetterLine: 10 > 0 = true → BestPriceListLine = 10%
Result: 10% applied. Correct.
The destructive Clear(BestPriceListLine) on PriceCalculationV16.Codeunit.al:256 is the culprit. It wipes out the good discount because the new line is "more specific" (has variant), but then the new line can't actually replace it because its discount is worse.

Note: even with a positive variant discount (say 5% vs 10% item), the specificity logic is still wrong — the 5% variant line wins in both orders because IsDegradedLine blocks the 10% item line from even competing. The order independence you see only applies when the variant discount is exactly 0

we need to find solution for both scenarios