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

Сталкивался ли кто-то с такой проблемой уже на 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) чаще бывает, что когда проводят тучу этапов производства и кто-то еще сильно блокирует базу, то накапливается очередь разного рода заданий и например нифига состояния у документов не обновляются и потому пришлось запилить инструмент просмотра и регл задание предупреждающее, что есть проблемы в очередях, большая задержка обработки

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

(10) вышла 2.5.25.80
Учитесь фиксить ошибки как фирма 1С после обращения)))

Все, что выше 15,2 принять равным 9999999999999,99

(15) Плохо, когда регулярно... Надо бы один раз сесть плотно, разобраться, исправить код и забыть )

Почему именно ВР? Может потому, что они чаще всего отрицательны, например: НУ = +1000 ПР = 0 и ВР = -1000
А в методе СЛУ где-то ошибочно ABS заложен и он не умеет работать с "отрицательной" якобы себестоимостью?

(18) ВР расчетный, его считают там в закрытии месяца просто по формуле ВР = БУ - НУ - ПР
Но это абстрактно, так как БУ это на самом деле куча суммовых полей: СтоимостьРегл, Стоимости постоянные, переменные,.... куча полей.

БУ, НУ и ПР считают применяя СЛУ.
И вот решение СЛУ по НУ херню выдает и как итог это отражается на ВР, так как ее в самом конце расчета налоговых сумм считают.

В любом случае, если 1С не забьют на нас, то возможно снимут себе с нашей базы слепки Узлов, Связей и у себя попробуют погонять алгоритмы решения СЛУ.
Пока нас более менее спасло, то что в конфигурации еще поддерживается программный расчет СЛУ, сегодня его смотрел, там конечно интересно реализовано, гоняют в цикле некий запрос насилуя скуль и как достигается некая точность расчетов, то прекращается насилие над скулем.

Может матрица в СЛУ плохо обусловлена?
Пробовал платформенный механизм для матриц Годунова - рассыпалось на размерности 67.

Программный расчет, если не ошибаюсь - итерационная схема Зейделя.

(20) Сложно сказать, что там не так.
На входе СЛУ получал как правило свыше 160000 узлов, и связей под 2 миллиона.
Сами узлы и связи получаются алгоритмами конских размеров. По движениям товаров строятся графы, разбиваются на подграфы... Не имея нужных инструментов визуализации фиг там что найдешь.
На демо базе все идеально. Знать бы как сломать, ввели бы кривые данные в базу чтобы ее заштырило, так же как рабочую.

Вся эта платформа 8.3.27 = мусор
Что не релиз, новая порция ошибок.
Перешли на 8.3.27.1936, теперь в ЭДО не открываются PDF файлы и происходит вылет клиента, ну или через раз, или просто перемещаясь по вкладочкам при просмотре дока пришедшего по ЭДО, там предпросмотры показываются и хопа вылет клиента фатальный.

По СЛУ
https://forum.infostart.ru/forum9/topic329242/
https://bugboard.1c.ru?state=er-000177951

(23) [Вся эта платформа 8.3.27 = мусор ]
да, после 1606 постоянный регресс

(23) Так это платформенная приблуда шуршит чёрным ящиком?
Тогда плюньте на ВР, формально укажите перед расчётом, что у вас как-будто балансовый метод ПБУ18/02, а не затратный, где на каждый чих считают ПР и ВР.
Пусть балансовый метод спокойно прошуршит отдельно БУ и НУ, а в конце суммарно сообразите куда разницу засунуть: на ВР и(или) на ПР.

Не родился ещё такой налоговик, чтобы проверять ВР на каждом чихе. Ему месячные суммы нужны )

Мне вообще не нравится точный расчёт системы сотен тысяч неизвестных, пусть и линейной. Это как если бы Больцман вместо термодинамических уравнений принялся бы изучать ньютонову механику сотен тысяч молекул.

(25) открой в конфигуратор ERP 2.5 и найди в Рг СебестоимостьТоваров/ПрочиеРасходы ресурс, хранящий стоимостную оценку НУ

когда обломаешься - принеси ТС-у извинения

(27) Что-то перемудрили с НУ в ЕРП. Простейший метод совокупности расходов превратили в какую-то расчётную монстру. В НУ не надо знать себестоимость красных яблок и зелёных. Нужны просто фрукты за месяц.
Это в УУ изголяйтесь как хотите )

(28) по делу что-то будет ?

(29) Нет. Это я чисто теоретически... пробую понять методические ошибки )

(25) балансовый метод и стоит, суммы НУ пустые, это не хорошо, а как следствие ВР выросли, хоть на них и насрать, но  причина и следствие налицо.
ПР и ВР у нас уже не скрываются штатно в базе, так как ранее учет велся с их применением в полном объеме

(23) Понравилось вот это в описании ошибки на картинке:
Если система линейных уравнений не имеет решения, то для всех узлов этой системы возвращается ноль...

Был у нас один аспирант, как-то перед защитой глянул я его формулы и вижу, что он убрал степень 3/2 в игреке с точкой (производная по времени). Наш диалог:
- ???
- А так дифур становится линейным и его проще решать!

(27) Да все верно, в регистре себестоимости нет ресурса НУ. Он выводится в форме набора записей расчетным путем в запросе динамического списка НУ = БУ - ПР - ВР
При просмотре отчета по движению регистров НУ не видно

(31) А почему НУ пустые? Бухгалтера забывали заполнять?

Ну пусть забывали... откуда арифметическая раскачка на миллиарды прёт? Не должна. В худшем случае алгоритм будет вечно считать, но не раскачиваться.

Раскачка пойдёт только при нелинейности, например, при методе наименьших квадратов или при другом нелинейном приближении.

(34) Ну как бы НУ расчетные всегда хоть ты видишь или нет ПР и ВР, конфигурация ВСЕГДА их считает и потом рисует колонку НУ (НУ = БУ - ПР - ВР)(хотя ее физически в базе нет) в отчетах или где еще нужно. За отображение ПР и ВР отвечает функциональная опция, как понял зависящая от того была ли в базе хоть по какой либо фирме установлена учетная политика учета этих ПР и ВР.

(36) Не понял. Чего ни коснись, всё у Вас расчётно. Как раз в балансовом методе, где нет ПР и ВР, сама бухгалтер решает, какую сумму в НУ пробивать для условно 1000 в БУ: хоть ту же 1000, хоть 600, хоть 200, хоть 0. Не должна эта сумма расчётно определяться, никак не должна. Человек решает в балансовом методе.

Потому и трудно потом его налоговикам проверять, потому что нет равенства БУ = НУ + ПР + ВР

Ладно. Повторюсь: надо тем, кто в ЕРП, плотно садиться и разбираться с этой светотенью )

(35) Там танец цифр начинается после расчета БУ НУ ПР ВР
Чем больше полуфабрикатов, переделов, тем веселее циферки.
На картинке пример одной из номенклатур готовой продукции
Сделана она на 27.1606, когда было обилие прям пустых НУ сумм после решения СЛУ и в итоге эти НУ=0 завышали ВР при расчетах
СЛУ нулей как понимаю нарешал и потом понеслось искажение математик в разного рода запросах потребляющих этот результат...

(37) покажите куда она это вводит в документе этап производства ну или хотя бы в приобретении товаров
мы же тут не про БП 3.0 тему трем

(37) ты не понимаешь разницы между:
- архитектурой хранения стоимостных оценок БУ и НУ
- точек ввода стоимостных оценок
- методики формирования оценок в процессе закрытия периода

повторюсь, в ERP учёт ведётся на Рг

(39) Глянул демо. Действительно негде вводить. А в проводках есть. Скорее всего в настройке формирования проводок заложена формула типа НУ = БУ.
А почему же на картинке такая хрень?
Можно глянуть верхний этап производства. Почему НУ не равно БУ

(40) согласен
Даже, если в ERP где и есть возможность ввести явно сумму НУ, то так как ее хранить негде, будет произведен расчет суммы ВР, а НУ улетучится (речь про регистры, в документе та останется)
допустим ПР = 0
ВР = БУ - НУ - ПР

Если БУ = НУ
то ВР = 0

Если БУ <> НУ
то ВР <> 0

А имея на руках БУ ПР ВР всегда можно вычислить НУ и втулить его туда куда нужно, отчет и тому подобное

(41) все тестовые базы на радостях снесли и уже предпоследние 77 релизы, а на них СЛУ решались без платформенного механизма

(41) Это ERP, там все сложно с расчетом с/с
По данным партий строятся таблицы узлов, просчитывается граф, подграфы. У считай каждого расхода есть свой номер НомерУзла. За каждым номеров узла стоят суммы полученные ранее, остатки на начало месяца и обороты, обороты если правильно понял содержат количество и если это приходы извне, то и суммы ибо приходные документы их явно прописывают.

Налоговые сумм да и БУ считаются СЛУ по списку Узлов и связей этих узлов между собой, там данные сложно по этому поводу еще подготавливаются, нормализуются...

Ближе к концу получается таблица ДвиженияТаблицаКорректировки в которой только движения с видом Расход
Каждое движение это по сути некогда те самые узлы, только уже у них нет привязки к старым номерам, номеров вообще нет, и вот у каждого этого узла некогда были рассчитаны суммы, сумм дофига в регистре.

Количество - да не сумма но оно есть
Стоимость
СтоимостьБезНДС
СтоимостьЗабалансовая
СтоимостьДопРасходы
СтоимостьДопРасходыБезНДС
Трудозатраты
ПостатейныеПостоянныеСНДС
ПостатейныеПеременныеСНДС
ПостатейныеПостоянныеБезНДС
ПостатейныеПеременныеБезНДС
СтоимостьРегл
СтоимостьЗабалансоваяРегл
ДопРасходыРегл
ТрудозатратыРегл
ПостатейныеПостоянныеРегл
ПостатейныеПеременныеРегл
ПостояннаяРазница
ВременнаяРазница
СтоимостьНДД
СтоимостьУпр
ДопРасходыУпр
ТрудозатратыУпр
ПостатейныеПостоянныеУпр
ПостатейныеПеременныеУпр

А некорректно отработавший СЛУ для связанных узлов видать не всем выдал решение и как следствие Узел А впадает в узел Б, а тот в Ц, но из А ушло в Б 5 и не дошло, а Б в Ц передает уже 0.

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

Например есть документ этап производства, он формирует РАСХОД материалов в производство. Списывает их на НЗП.
Если память не изменяет, то в движениях хоз операция "производственные затраты", "аналитика номенклатуры" потребленного материала, а кор. операцию рисует как "выпуск продукции" и "кор. аналитику номенклатуры" куда потратили материалы, то есть ПФ или ГП.
Это же расход, а значит для расхода ранее вычислили стоимости этих узлов.
Если поменять аналитики местами, то получим
хоз операция "выпуск продукции", "аналитику номенклатуры" куда потратили материалы, кор. операция "производственные затраты", "аналитика номенклатуры" потребленного материала
суммы остаются на местах. Так получается стоимость ГП при выпуске.

По моему фото там еще есть передача из производства. Склад куда выпустилась продукция это кладовая, все еще 20 счет, а на 43 счет она попадет только после передачи ИЗ производства на нормальный склад.

И вот передача из производства это тоже РАСХОД, его тоже можно повернуть на изнанку
РАСХОД изначально это хоз операция "передача продукции из производства", кор. хоз операция "товары на складах"
наоборот это ПРИХОД  хоз операция "товары на складах", кор. хоз операция "передача продукции из производства"
суммы остаются на местах. Так получается стоимость ГП на складе.

По второму документу передачи из производства такая же история.

ОДНАКО!!! СЛУ поднасрал и суммы узла выпуска не равны суммам узлов передачи на склад.
Ту картину и видно на картинке выше

На картинке есть еще документ реализации, вот видимо СЛУ по нему так же порешал как и по документам передачи из производства, потому у них суммы и совпали.

(43) в итоге с программным СЛУ период в продуктиве закрылся ?

(45) да, но конечно ожидаемо подольше, но это наименьшее зло