Hello all, this is not a question but a fact which might be interesting to a lot of people: The best price finding does not allow to have newer prices overriding older prices without setting an end date for the old price. This does not match the old principle we all know and (hopefully) loved in previous Navision versions: Anyway, there is an small two line change which can overcome this issue. How best price finding works since 3.70 (the short version). Navision checks a lot of combinations of filters in the price table (purchase and sales) - and also for finding best discount. All the records matching these filters are put into a temporary price (discount) table. Now Navision loops through the temp table and finds the lowest price. Problem: When a price exactly matches another price (same primary key), except for the Start Date, the user would expect that the newer price (discount) overrules the older price (discount). But Navision does not. Solution: The following functions need to be changed to overcome this issue: CU 7010 Purch. Price Calc. Mgt.: FindPurchPrice FindPurchLineDisc CU 7000 Sales Price Calc. Mgt.: FindSalesPrice FindSalesLineDisc the changes to be applied are: when looping through the found record, before inserting into the temporary table, the “Starting Date” needs to be set to 0D and the temporary record should be inserted only if it can not be modified. example from FindPurchPrice: ... IF FromPurchPrice.FIND('-') THEN REPEAT IF FromPurchPrice."Direct Unit Cost" <> 0 THEN BEGIN ToPurchPrice := FromPurchPrice; // Find latest price only >>> ToPurchPrice."Starting Date" := 0D; IF NOT ToPurchPrice.MODIFY THEN // Find latest price only <<<< ToPurchPrice.INSERT; END; UNTIL FromPurchPrice.NEXT = 0; The result of this solution is: All records which only differ in the “Starting Date” field will now overwrite existing temporary records, whereby the oldest will be processed first in the repeat - until loop. So only the newest price (discount) will remain in the temporary record. Even when I said I will make it short, it is quite some information.
Thomas, thank you for pointing this out to us! It is really a big (and confusing) difference to the way it worked before. Best regards //Pelle
Really? I thought the pricing was a huge improvement than before. Now the user will be able to see clearly when prices start and end. It makes explaining pricing to the end user a whole lot easier for me. [:D]
Oddly this 3.70 pricing change was very well accepted in the US, and in fact was used as a selling point during demos. I think that it is more the way things are done in the US. But also the fact that as Thomas has pointed out, its much easier to modify the 3.70 pricing, than to change the old 3.60 system. For that reason alone, I prefer it. Having said that, definitely a 2.60 customer moving to 3.70 sees it as an improvement, but a 3.60 client moving to 3.70 sees it as a bug. Since I only ever did two 3.60 to 3.70 upgrades, I saw it as an improvment. [^]