Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Подбить процент в отчете
|
|||
|---|---|---|---|
|
#18+
Привет! От меня хотят сходимости сумм процентов в отчетах. Например, есть столбец Value1 11.2% Value2 12.3% Value3 23.7% Subtotal 47.3% (а хотят 47.2% - точную сумму предыдущих округленных значений) Твердолобо убеждают, что клиенту нужна такая показуха, и требуют "точного" совпадения. Я вообще не понимаю зачем это и не вижу в этом смысла. Но от меня требуют или переубедить или сделать как хотят. Так я не нахожу доходчивых аргументов или меня просто не хотят понять. Может, существуют стандартные решения? Я думаю не я первый не я последний считаю этот процент... Как вообще добиваются сходимости в подобных отчетах? И нужна ли она? Если у кого есть мысли по теме выскажите или какие ссылки приведите please... (Сам ищу) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 12:58 |
|
||
|
Подбить процент в отчете
|
|||
|---|---|---|---|
|
#18+
Ну и сделайте им сумму ячеек Value, в чём проблема? В форматировании ? Eсли надо, перед сложением округлите значения Value также, как они отображаются. Другое дело что общая их сумма может не быть точно 100% Предупредите. Или предложите отображать две значащих цифры после запятой. Но это конечно всё равно не решит проблему так, как им требуется. А вообще, действительно маразм. Если число округляется, то точность теряется. Это азы. И проходят это в школе. Пусть они вам это требование на бумаге напишут. С подписью и печатью. А вы обдумайте формулировку которую от них потребовать. Например "значение процентов субтотал должно вычисляться как сумма отображаемых значений процентов Value". Вот и всё - что хоЧУТ то и получат, с Вас взятки гладки. Найдите какой-нибудь текст по описанной проблеме, подтверждающий Вашу точку зрения. Поищите в Гугле например на "потеря точности при округлении". Значение субтотал, подсчитанное не непосредственно, а путём суммирования отбражаемых округлённых значений Value будет по сути обманом клиентов. Можете на эту тему написать служебную или докландую записку и пусть её у Вас примут с датой и входящим номером, проставленными на Вашем экземпляре. Но конечно смотрите по обстановке. Возможно не стоит гнать волну. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 13:37 |
|
||
|
Подбить процент в отчете
|
|||
|---|---|---|---|
|
#18+
Вот ещё по Вашей теме, возможно будет полезно: SSRS2005 & round ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 13:52 |
|
||
|
Подбить процент в отчете
|
|||
|---|---|---|---|
|
#18+
Сделаю все расчеты в хранимой процедуре. Буду делить (считать проценты) в decimal(*, заданное число знаков после запятой), а суммировать уже эти decimal (они уже округлены)... Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 16:01 |
|
||
|
Подбить процент в отчете
|
|||
|---|---|---|---|
|
#18+
Я бы рекомендовал как источник данных для отчета использовать не хранимую процедуру а табличную функцию. Она "легче" - требует меньше ресурсов. Но вам виднее. Хранимые процедуры могут иметь преимущество, если требуется использовать для многопроходной обработки временные таблицы с индексами. В функциях же, в отличие от процедур, временные таблицы запрещены. Однако, как правило, табличные переменные служат для тех же целей достаточно хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2008, 13:06 |
|
||
|
|

start [/forum/search_topic.php?author=buraner&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
17ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
| others: | 2497ms |
| total: | 2662ms |

| 0 / 0 |
