Skip to main content
Solved

Bug? Sales Quotations view

  • February 25, 2026
  • 3 replies
  • 28 views

Forum|alt.badge.img+5

In previous IFS versions we were able to see the value of Closed (status) Lost (state) sales quotations in the Sales Quotations view. 

 

In current version 25R1 the total net prices for lost quotations is 0.00 even if there are product lines with values in the lost quotation. 

Current versions still show values for Closed and Won quotations.

 

Is this is a bug or a change that have been requested?

 

This affect negatively the possibility to deep dive into analyzing sales quotations and specially the lost ones. We have thousands of annual quotations to analyze, and it is not practical to open each quotation separately and combining the quotation value in excels...

Best answer by Sayuri Perera

Hi ​@linjen ,

The behavior you have explained is a change introduced in 24R2 tracks and beyond. As per this change,

> The lost value line amounts will not be retained in the sales quotation (SQ) header.

> However, the initially quoted value should remain at the individual SQ line level.
> Additionally, the lost value will be removed from the sales quotation report as well.

 

This functionality was introduced following the release of 24R2 via SCZ-26304, after thorough internal discussions regarding the requested requirements. A specific issue was identified concerning having amounts of 'lost' lines in sales quotation header when having multiple lines and only few lines are 'lost'.

The newly implemented behavior ensures that the header level totals exclusively reflect the won line totals, thereby excluding any lost lines. This consistent behavior is also observable when the quotes are printed.

The primary purpose of this functionality is to rectify the issue of potentially misleading total amounts in the sales quotation header. However, as you have noted, in cases where there is only one line or all lines are lost, the sales quotation header will display values as 0. You will need to refer 'lost' line price details to check for the values in that instance. Hope this clarifies your concern.

 

If this resolves your question, please mark it as the best answer. So that it will be helpful for other peers.

Kind regards,

Sayuri.

3 replies

Forum|alt.badge.img+12

@Sayuri Perera  - could you please help with this question?


Sayuri Perera
Hero (Employee)
Forum|alt.badge.img+9
  • Hero (Employee)
  • Answer
  • February 26, 2026

Hi ​@linjen ,

The behavior you have explained is a change introduced in 24R2 tracks and beyond. As per this change,

> The lost value line amounts will not be retained in the sales quotation (SQ) header.

> However, the initially quoted value should remain at the individual SQ line level.
> Additionally, the lost value will be removed from the sales quotation report as well.

 

This functionality was introduced following the release of 24R2 via SCZ-26304, after thorough internal discussions regarding the requested requirements. A specific issue was identified concerning having amounts of 'lost' lines in sales quotation header when having multiple lines and only few lines are 'lost'.

The newly implemented behavior ensures that the header level totals exclusively reflect the won line totals, thereby excluding any lost lines. This consistent behavior is also observable when the quotes are printed.

The primary purpose of this functionality is to rectify the issue of potentially misleading total amounts in the sales quotation header. However, as you have noted, in cases where there is only one line or all lines are lost, the sales quotation header will display values as 0. You will need to refer 'lost' line price details to check for the values in that instance. Hope this clarifies your concern.

 

If this resolves your question, please mark it as the best answer. So that it will be helpful for other peers.

Kind regards,

Sayuri.


Forum|alt.badge.img+5
  • Author
  • Sidekick (Customer)
  • February 26, 2026

Thank you Sayuri for the reply. I understand the logic in IFS have changed, and we will have to create a workaround for this.