Неправильные итоги под 1С 7.7 SQL #392584

На 25-ом релизе. Какой релиз сейчас наиболее стабилен? Интересует именно опер. учет.

27-й разумеется.

Что значит "неправильные"?

А разрядность проверял?

Что-то у меня есть сомнения... Округление итогов до целого в запросах. Есть приход например 235,348 Есть расходы - все целые, остаток в итоге 0.348 Запрос с одной группировкой по этому товару (это измерение) выдает 0. С группировкой по документам движения выдает 0.348 Замечали неоднократно по разным регистрам. Глючат в том числе и типовые отчеты. Проверял. Всё нормально с разрядностью. период с начдата по кондата; Группировка товар без групп;

если есть сомнения, то отсыпай :-0

Это предположение, или точно известно что в 27-ом были исправлены ошибки опер. итогов 25-го?

Я последние 4 года не видел ни разу.

"Округление итогов до целого в запросах" - дык запросы очень разные бывают. В том числе, и те, что и должны до целого округлять. Точнее, должны это делать с точки зрения 1С.

Это шутка? Я очень рад тому что 27 релиз (которому 2 года отроду) не глючит уже четыре года...

Почему шутка??

с залипухой включтьsql тоже самое ? Мот того, пересчитать итоги просто?...

>>"Есть приход например 235,348 >>Есть расходы - все целые, остаток в итоге 0.348 " А какой должен быть остаток, если "Есть расходы - все целые"  ????

+12 а...не дочитал до конца.. звиняйте..

Хотя не.. Каким боком относятся Останки с "группировкой по документам движения"  ?????

Глюк такой. Если в запрос добавляем функции приход и расход, и добавляем группировку Документ (и берем период в котором находятмся все приходы и расходы) - то КОНОСТ по товару выдает правильное количество. Очень похоже на глюк 18-го релиза, но глючит немного по-другому. Потому что я выложил пример запроса. Извесный глюк это округление остатков в функции сумма с вложенной внешней функцией - но тут функция коност Ситуация такая - фирма работает круглосуточно, выгнать всех для пересчета итогов - это простой, потерянные деньги. Выгрузка/Загрузка невозможна, пересчет итогов - долго (база 10 гигов) То есть выгнать можно только один раз. Варианта три - переход на 19,21 или 27-ой релиз. Я вообще попробую смоделировать ситуацию на пустой конфигурации с одним регистром и одним документом, может получится отловить глюк конкретней.

"выгнать всех для пересчета итогов - это простой, потерянные деньги" - пардон, на такая маленькая база пересчитается за несколько десятков секунд. И выгонять никого не надо.

Покажи скульный запрос, который выполняет 1С-ка для запроса из (;) ?

+ из

Пересчитай прямым запросом за требуемый период. Это секунды, макситум - минута...

Опять "кристобаль хозевич успел раньше..."

ты чо нарк?

не могу. Я сейчас не у клиента. Предлагаешь пересчитать все итоги по всем регистрам, и переписать все отчеты в базе?

Разумеется. По крайней мере, некоторые участники в этом уверены.

т.е. щас стоит 18 ?

Если даже я моментально пересчитаю все регистры - нужно еще проверить глючат ли отчеты. сейчас стоит 25-ый.

А Сумма в запросе кстати, "не глючит", а берёт точность из переменной текста запроса.. а вот когда её заставляют вычислять некоторое выражение, в котором не участвует переменная текста запроса, объявленная выше - то точность взять неоткуда , и по-умолчанию =0. Вот и "округление".

Да, я знаю. Я просто отвечаю Садовникову, что в моем случае не должна округлять.

В ссылка на обработку, которая как раз прямыми запросами перечситывает регистры. Хоть все, хоть по отдельности. Каюсь, не обратил внимание на запрос, когда писал .

Спасибо. Теперь остался другой вопрос - кто-нибудь сталкивался с таким глюком на 25-ом, и переход на какой релиз спас...

Ты, лучше, как сможешь, запрос покажи. Там и станет понятно где чей глюк.

Если бы только один отчет врал... Подобные округления происходят во всех отчетах. Точно есть подобный глюк по типовому остаткиТМЦ, в типовых отчетах (это я видел) И по типовому Продажи (оборотному) - это со слов пользователей.

Так одного простого показательного должно хватить для разбора полетов. Ну и типов данных, хранящихся в регистре.

Несколько баз, SQL, размеры от 10Г до 65Г, релиз везде 25, такого глюка не наблюдал... Итоги бывает, слетают...  лечатся выборочным пересчетом по конкретному регистру - конкретному измерению регистра.

+33 Тоже не видел... итоги слетают иногда тоже. 25-ый.

Если я тоже скажу, что не видел - будет очень непоказательно... Хотя, правда, не видел.

Ситуация очень редкая, на практических данных не встречается... (приход дробный, расход только целый) - может поэтому не было таких глюков? Именно слет итогов тут не при чем, так как все движения в одном периоде итогов - то есть идет расчет коност на лету. Но насколько я понял из-за неправильного расчета переносятся неправильные итоги на следующий период.

Удивляешь.... если "переносятся неправильные итоги на следующий период" - это и есть классический слет итогов. А если "странные данные" выдает запрос - надо лечить именно запрос

Может в последний расход включать закрытие значений меньших 1, если фактически их нет на складе?

На начало месяца итогов нет. Данные только в этом месяце - коност выдает неправильное значение - это не слет итогов (кондата раньше ТА и раньше конца месяца) Слет итогов когда только переносятся неправильные итоги, а отчет за кусок предыдущего периода выдает правильные значения. Эти неправильно рассчитываемые итоги переносятся на следующий месяц - это не слет итогов, а неправильный расчет, но то что неправильные итоги переносятся на следующий месяц - это не утверждение, а предположение. И как запрос из можно вылечить? 0_0 Нельзя. Во первых нужно четко контролировать приход/расход чтоб не воровали, во вторых это вет. справки, с ними  мухлевать очень накладно, а в третьих очень плохо когда у сотрудников появляется отмазка "программа неправильно считает" - у них эта отмазка появляется на все случаи жизни.

а приблуду Запрос.ВключитьSQL не пробовал ?..

Включи еще в запрос нач остаток, приход и расход. И посмотри. Для очистки совести, сделай запрос на ТА, и сравни с тем, что фактически лежит в итогах регистра. Для полной очистки совести сделай то же прямым, и найдешь, где ж порылась собака. Но - имхо - от разрядности, если ты ее не превышаешь - ничего зависеть не должно.

Если включить в запрос приход и расход то запрос начинат работать правильно (с группировкой). Нет не пробовал, попробую. Разрядность не превышаю - пять знаков после точки. Но если ошибка исчезнет - это ничего не меняет. Все отчеты не переписать (слишком дорого встанет клиенту) , а включитьSQL  даст тормоза.

Если включить в запрос приход и расход то запрос начинает работать правильно (с группировкой документ). Без группировки по документам не пробовал.

Всё-таки я был прав. Есть ошибка в 25-ом релизе с итогами в черном запросе под SQL.

Самое прикольное, что ту ветку я тоже читал раньше :) а на 27 нормально работает ?...

подобное было если разрядность регистра больше 2х знаков после запятой, помню долго боролся, поборол (правда давно уже было)

Да, больше. Еще не проверял. Но думаю что всё будет нормально.