Всем привет. Второй раз открываю тему. Прошу прощение за дубль. Такая проблема нарисовалась. Есть УПП база и в период с 30.12 по 05.01 произошли какие то изменения в базе, после этого расчет себестоимости при перепроведении за любой период выдаёт миллиардные минуса. Эталонная база от 30.12 и база 05.01 где появляются эти ошибки идентичны конфигурациями, настройками, справочниками и т.п. Все минуса убрал, но при расчете себестоимости выводится такое сообщение
Проведение документа: Расчет себестоимости 00000000014 от 31.01.2013 23:59:59
Выполненное количество итераций расчета стоимости: 30
Выполненное количество итераций расчета стоимости: 50
Полученное среднее отклонение решений: 41 651 508 092 792 837 314 439 674 422 852 366 027 260 323 265 825 168 662 628 812 082 253 857 244 883 943 368 245 128 623 936 773 009 401 716 380 098 119 211 969 845 410 767 284 324 949 426 259 476 326 885 740 157 044 558 353 934 693 427 368 938 623 869 720 383 287 540 496 109 992 483 928 408 052 095 259 772 383 421 093 039 637 650 851 957 723 520 864 754 459 873 330 705 799 496 507 397 124 924 048 749,375428
Расчет себестоимости завершен.


И появляются огромные минуса. Куда копать, что смотреть? Уже все перелазил. Журнал регистрации, к сожалению, удалили сисадмины, т.к не хватало места.

Перепроводил документы. РАУЗ

причина - это зацикливание.
т.е. либо что-то выпустили само из себя, или сделали комплектацию.
А возможно банальная химия с ТМЦ, например на начало 1, списали 501 а в конце месяца выровняли оприходованием 500. В КА11 точно РАУЗ взбесится, в УПП думаю тоже.

(2) как это проверить всё?

Ну ты спросил.
Но тебе я так понял повезло и Расчет завершается.
В итоге у тебя ОСВ должна быть с не влезающими цифрами.
Отсюда и пляши, смотри какой счет и проваливайся в низ.
Если это материал то найдешь его в ОСВ.
Ну а далее в РАУЗ и ищи причины, там может копейка с предыдущего повиснуть и дать в этом периоде переполнение.
Может просто РАУЗ нужно поднастроить, увеличить порог округления.

(4) РСВ только по управленческому учету проводим

ну значит смотри отчет по РАУЗ сразу по упр, там увидишь большие цифры. Настрой его по ключам аналитики
Плохо было бы, если РСВ валился бы при проведении.

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

https://yadi.sk/i/_iRQumW-vF9lhQ
РСВ веселиться.

И так умножая постоянно на 4 он приходит к триллионным минусам

(8) Только 26 счет не закрылся?

(10) К сожалению, не разбираюсь в счетах. Только программирую. Но если я вас правильно понял, то проблема не только по тому виду учета, который отображен на скрине, а по всем.

Обращался к другим специалистам, тоже молчат, давали рекомендации стандартные по исправлению минусов, и настройке рсв. Все проверили, исправили, не помогло.

Просто разве нет больше каких-нибудь универсальных методов решения, где посмотреть, увидеть ошибки, на что смотреть? Почему именно в 4 раза увеличивается списание РСВ

(13) есть. Пофигуратор ответит на все вопросы

(14) А вы смотрели код РСВ в конфе? Сложная, очень сложная вещь. Но видимо, если никто не поможет другим советом, придется там засесть. Но, по моему, это не целесообразно, больше времени уйдет разбираться в коде расчета РСВ, нежели поставить базу на 30 число этого года и догрузить туда документы до сегодняшнего. Но мне то необходимо было понят ьв чем проблема

(15) не раз. Ничего сложного. Жуколовом находится всё.
Весь затык, в основном - неверное заполнение регистров по аналитикам учета

АналитикаВидаУчета/АналитикаВидаУчетаЗатрат и прочей хрени
+ неверные записи в справочнике КлючиАналитикиУчета

(17) да они идентичные в обеих базах. Проверял уже много раз. Вот только в одной базе от 30 числа минус 9 триллионов, а в другой  все в порядке. Конфигурации тоже идентичны, ключи и т.п.

У тебя списание происходит кратное количество раз?
т.е. ровно в два, три и т.д.?

Почисть ключи аналитики. Не помню как там меню называется.
Но что-то типа "Тестирование, исправления ключей аналитики" обработка удалит лишние ключи. У тебя каким то образом задвоились ключи. Как так получается я не знаю, но последствия встречал неоднократно.
Если Тестирование не уберёт проблему, то придется танцы с бубнами, так как ключи аналитики не редактируются, то нужно будет выявить дублирование и удалить один из них.

(13) Сколько дублированных ключей, во столько раз и умножает.

Я обычно перед закрытием, делаю Тестирование ключей, потом например перепровожу документы, и снова Тестирование потом РСВ

(20) Тестирование и удаление не помогает. В базе, где все хорошо закрывается дубли есть, где все плохо - дублей нет. Дело не в этом.

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

(22) Ключи не имею одинаковое наименование , проверял "Поиск и замена дублирующих элементов"

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

(24) Если миллиарды кратные целому число - это ключи
Если просто большие числа - это не верная сходимость СЛУ в РАУЗ. А в твоём случае возможно и то и другое. :(

Если я найду инструкцию от 2011 года одного моего "студента", он описывал процесс восстановления ключей при кратном списании при РСВ на базе УПП, но точно такую же ситуацию я встречал и на КА1

(24) ну, если ты считаешь что с ключами всё ровно, то для начала, пересчитай итоги в базе.