При закрытии месяца программа криво закрывает налоговый учет, где она формирует лишние движения с "Операция учета себестоимости" = "Списание на другие партии". Речь о регистре себестоимости.
В этих движениях она отражает количество и суммы по ПР и ВР.
При этом суммы ПР и ВР такие же как в движениях по передаче продукции из производства "Операция учета себестоимости" = "Перемещение".
В итоге, если делать отбор по партии и товару в регистре себестоимости Приход и Расход, то по ПР и ВР отличается по итоговой сумме. По Расход больше выходит чем приход и получаем на остатках зависшие минусовые ПР и ВР по партии.

Сталкивался ли кто-то с такой проблемой уже на ERP 2.5.25?

Белеберда какая-то с этим закрытием месяца, пока голова не переваривает, да и отладчик не поможет ибо одна попытка, - это мнооого часов ожидания.

Пока понятно, что при передаче ИЗ производства на склад прога теряет сумму НУ и потом как следствие высчитывается большая ВР.
ВР = БУ - НУ - ПР
По большей части получается ВР = БУ ибо и ПР часто 0
Потом по ВР и получается минус больших размеров на остатках (в цехе) после передачи продукции на склад для последующей продажи.

(1) с 25 релизом не работаю(только LTS), как следствие советы общего плана:
- сделать минимальную модель, по новому юр.лицу, запулить начальные остатки и короткую цепочку документов для воспроизведения ошибки
- обновить модельную копию до крайнего релиза, возможно отсутствие в баг-тракере данной ошибки не означает парирование
- и рабочий вариант в запросах выборки данных для себестоимости воткнуть свой патчик для расчёта ВР и ПР по БУ и НУ, у меня со времён 2.5.7 так сделано для ряда хоз.операций

(2) неделя ебли, выгрузка 25+ гигов всяких временных таблиц... Изучение данных...
В платформе 27.1606 нормально не решаются СЛУ.
Обновили тестовый контур на 27.1936. Вроде суммы НУ после решения СЛУ стали появляться, однако потом одна из баз легла во время расчета со скулевой ошибкой арифметического переполнения...
Теперь туда копать и смотреть. Возможно качество данных после СЛУ такое себе, что приводит к переполнениям

Вести с полей)))

Ну что, в 27.1936 СЛУ так "хорошо решаются", что это приводит к вроде бы появлению местами верных сумм ВР (НУ больше <> 0)(СЛУ в базе решаются по БУ, НУ и ПР, а ВР напомню вычисляется как ВР = БУ - НУ - ПР), а в некоторых местах этот ВР такой большой становится, что получить можно легко ошибки вида

Ошибка при выполнении операции над данными:
Microsoft OLE DB Driver 19 for SQL Server: Ошибка арифметического переполнения при преобразовании numeric к типу данных numeric.
HRESULT=80040E57, SQLSrvr: SQLSTATE=22003, state=8, Severity=10, native=8115, line=1

Как такое выходит? Ну есть такие формулы в запросах например как

ВЫРАЗИТЬ(ДД.Количество * ЕСТЬNULL(Цены.ВременнаяРазница, 0) КАК ЧИСЛО(31,2)) КАК ВременнаяРазница

А потом идет другой запрос, который делает так

ВЫРАЗИТЬ(ДС.ВременнаяРазница КАК ЧИСЛО(15,2)) КАК ВременнаяРазница

И падает скуль, если число исходное не втиснуть в 15,2

Все 100% типовой код)))

Так для примера, некая готовая продукция стоит 1 мульт, а ВР прога насчитала 4 280 404 494 205,32 руб

(4) кейс интересный и да, переполнение бывает

(5) Коллега на ночь в этот раз ставила закрытие, но включили назад программное решение СЛУ без платформы, на первый взгляд сказала, что вроде вернулось все в норму. С утра сразу запустила расчет на рабочей базе, где так же у СЛУ отключила платформенный механизм. Потом отпишусь помогло ли в реальности. Мечи уже над головами взведены. Стресс нарастает)))

(5) забавно и то что попытались выйти на 1С ИТС, открыли им RDP и дали настройки подключения к VPN, а они якобы не могут подключиться, хотя админюки все проверили. А может дурочку включили. По итогу от ИТС помощи не смогли получить никакой.

(7)

А с взаиморасчетами у вас все хорошо ?

У нас 2.5.25.63 и этот релиз не перестаёт меня удивлять, увы.

(8) ушли вчера на версию 2.5.25.77
Что у вас за проблемы?
Нужно понять куда смотреть, а то может и у нас они есть

Глянул типовую демо 25.68
Нет в коде ни одного вхождения ДС.ВременнаяРазница
Я правильно понимаю, что автор дописал что-то своё, указал 15.2 и теперь удивляется арифметическому переполнению?

(9)

Если в РС.ЗаданияКРаспределениюВзаиморасчетов нет записей - то проблем (наверное) нет.

В 2.5.25.63 1С забыли дописать код, который бы разбирал этот РС и выпускали патч EF_00_00800566
В вашей версии обновления код патча уже включен в основной код.

По их задумке при проведении документа (например РТУ) пользователем,
пользователь порождает фоновое, которое разбирает этот регистр.

Но вот беда, оно разбирает под "ДатаЗапрета" пользователя, а разобрать хочет гораздо больше,
разобрать не может и плачет об ошибках.

(10) я упростил пример потому как, если описывать все, то люди устают читать


РасчетСебестоимостиЗаполнениепартий.ПересортицаПартийТоваров

Там запрос где 31,2

Потом формируется запрос копирующий данные из той таблицы в ВТДвиженияСебестоимости
Потом вызывается РасчетСебестоимостиПрикладныеАлгоритмы.КэшироватьСформированныеДвиженияИзВременныхТаблиц

ВТДвиженияСебестоимости = регистр СебестоимостьТоваров и из этой таблицы данные копируются в типа кэш этого регистра при этом данные приводятся к тому типу как у регистра, а суммовые поля там 15,2

(11) видимо мы это пережили незаметно и возможно патч уже был на момент обновления

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