Please refactor UpdateUnitPrice in T37

[GuntherGebauer]

in T37 in UpdateUnitPrice it is the sequence that first PriceCalcMgt.FindSalesLineLineDisc is executed and then later PriceCalcMgt.FindSalesLinePrice.

I think this sequence is wrong, because the FoundBestPrices have the field SalesPrice."Allow Line Disc." set to FALSE or TRUE depending on the actual BestPrice which has been found.

So the BestPrice determines whether line Discounts may be searched and used or not. (In case of Special customer Prices you do not want to offer additional line Discounts on these Prices).

The actual Routine sequence in T37 UpdateUnitPrice does not allow this and the eventtrigger also do not offer any possibility to solve this Business case, as there is also no possibility to suppress/omitt the execution of FindSalesLineLineDisc (which is not necessary and not useful if SalesPrice."Allow Line Disc." = FALSE)

[IhorHandziuk]

Hi @GuntherGebauer ,

It appears to me that the system works as designed: 1) identifies maximum possible discount, let's say it appears to be 20% 2) walks through prices and tries to select the best one (considering the property "Allow Line Disc.") So if we have two prices: 100 (with ."Allow Line Disc." = FALSE) and 120 (with ."Allow Line Disc." = TRUE) the second one will be chosen (because of the discount calculated on step 1) 3) set "Line Discount %" to 0 if best price has "Allow Line Disc." = False.

If I understood correctly, the suggestion is to give the possibility to skip the execution of FindSalesLineLineDisc? Can you, please, explain why exactly the business case requires it instead of setting "Allow Line Disc." to false for special customer prices?

[GuntherGebauer]

Hi @IhorHandziuk, my Suggestion is Start with Step 2, so 100 is the bestprice to be used, and not 120 if "Allow line Disc."=True then Step 1, so no Discounts in this case with Price=100 do not execute step 3

we have our own Discount Determination: we can define more than 1 Discount%, calculate the total Discount amount from rest or on total, back to NAV we set the calculated Discount amount/percentage - so we Need Extension trigger to find and calculate our own Discounts. our separate Discounts are stored in separate tables and moved during Posting to posted Discounts. So Discount calculation is difficult and consumes Performance and we are glad if Prices define not to calculate Discounts.

we have our own price calculations because the best Price practice is not acceptable for our customers. we use also the Standard customer Prices, Action Prices and pricelists from customerpricegroups, but in two different ways (e.g. not limited to the "unit of measure Code")

so in both cases we would like to use our calculations and come back to the NAV Standard unit Price and Discount percentages, because we use the rest of the Standard calculation amounts, taxes and so on for Posting and statistics calculations.

OnUpdateUnitPriceOnBeforeFindPrice seems to be the best way to use our calculations, but at the Moment we have the programming Code inside codeunit 7000 in FindSalesLineLineDisc and FindSalesLinePrice to use most part of the Standard. Maybe we must redesign this programming and stay with the existing Event trigger of T37.

[StanPesotskiy]

Resolved by adding an event OnUpdateUnitPriceOnBeforeFindPrice() to PROCEDURE UpdateUnitPrice():

CASE Type OF
        Type::Item,
        Type::Resource:
          BEGIN
            **IsHandled := FALSE;
            OnUpdateUnitPriceOnBeforeFindPrice(SalesHeader,Rec,CalledByFieldNo,CurrFieldNo,IsHandled);
            IF NOT IsHandled THEN BEGIN**
              IF NOT ("Copied From Posted Doc." AND IsCreditDocType) THEN
                PriceCalcMgt.FindSalesLineLineDisc(SalesHeader,Rec);
              PriceCalcMgt.FindSalesLinePrice(SalesHeader,Rec,CalledByFieldNo);
            END;
          END;