Механизм открытия периода оперативного учета? #180813

В комплексной 461 используются стандартные регистры и документы по УСН. После проводки документа Формирования записей книги учета доходов и расходов УСН открытие очередного периода оперативного учета (новый месяц) умираем для первого перехода минут на 50. Если ничего не делаем, а просто тут же открываем следующий месяц, 1.5-2 часа в поном ауте. При попытке перейти еще через один месяц больше не просыпаемся вообще, даже через сутки. Никакое тестирование и исправление не спасает. При отмене проводок этих документов ситуация почти не меняется. Как я понимаю, команда устаноки ТА при переходе через месяц на основе движений регистра и текущего состояния остатков формирует некоторым запросом новое состояние остатков регистра. Вопрос: что же там так фатально действует на этот запрос, что он уходит в глубокий аут? доки оригинальные фирмы 1С Кто знаком с механизмом переноса остатков, отликнитесь, плиз. Поделитесь опытом и знаниями...

Ну ты телепат и отколол...

ты знаеш, кто он?

А ведь он прав... Бэкапы - это святое!

конечно, робот

могу сказать, что для регистров остатков есть две таблицы в базе данных: движения и остатков.

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

да, две.

и дв регистра, итого 4 файла ra34759, rg34759, и еще одна пара

файлы живые. Если результатов работы этих двух доков в них нет, все ок. стоит провести их - плохо. снять с проводки, все равно плохо. Видимо запрос пересчета остатков молотит файлы, содержащие пусть отмененные движения, но лежащие в файле, и переварить этого не может???

+ хотел сказать перепроводим все, кроме этих доков

Сделай выгрузку/загрузку плюс упаковку таблиц плюс тестирование и исправление информационной базы. Предварительной сделай бэкап. Если в файлах таблиц регистров остался какой-то мусор, то после выгрузки/загрузки он удалится.

Сделано, не помогает.

что-то я не понял... база умирает при проведении доков определенного вида или при открытии периода или... ?

Мусора вообще нет. Эксперимент проводился, как я понимаю вчистую благо база всего 100 метров: 1.Бьем вообще все регистры - и остатки и движения (ra***, rg***) 2. заходим в базу и запускаем обработку проведения документов, включая галки на всех доках, кроме зарплатных и кроме формирования книги усн 3. проверяем - все ок. и регистры остатков, партий, и т.д. оперативный учет переходит с месяца на месяц на раз и т.д. 4. ручками перепроводим пару доков типа формирования книги усн - нормально проводится 5. пробуем перейти через месяц и умираем 6. снимаем эти доки с провдки. при переходе через месяц это уже не помогает

движений првда по этим докам порядка 1000 по каждому

релиз, место на диске и собсно качество этого диска, объем памяти... еще попробовать бы кол-во движений уменьшить, ну не больше тысячи на док.

релиз 25-й, лицензионный, тачка прекрасная Р4-3.2 2х512 оперативки, диски сата с памятью немеряной, хр сп2 лицензионный

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

кстати на разных тачках одно и то же

все это на одном и том же документе?

+22 или виде документов?

именно это и пробуется - после проводки доков ничего не делается вообще, кроме попыток переставлять ТА. Первый переход минут 50, второй 1.5-2 часа третьего не дано

Это стандартный док формирования закисей кудр за 3-й и за 4-й кварталл с 1-м и со 2-м все в порядке

кэш на диске выключен? автоматическое восстановление на нем же выключено?

кэш не выключен, восстановление выключено, думаешь существенно?

попытки делались на разных тачках с тем же результатом

перебираю варианты...

+29 еще можно вынести temp поближе, т.е. запускаем 1С с ключом: /tC:TMP (путь разумееется должен существовать)

А что если программно устанавливать точку актуальности УстановитьТАна(ТекущаяДата)

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

То же самое.

попробую, хотя странно все это тоже попробую, но опять же странно

В стандарте приоткрытии нового месяца эта команда и делается.

Может быть реализация команды разная.

???

Когда это делается напрямую платформой и когда это делается через через компиляцию встроенного языка.

Стр = "Не открыт период оперативного учета!                Стр = "Не открыт период оперативного учета!

Не платформой, а при начале работы системы

А база полностью типовая, или с серьезными переделками?

И хороши бы структуру регистров увидеть.

В эксперименте новые доки не участвуют

Доработанная, но доработки в основном по автоматизации заполнения типовых доков (по типу быстрой продажи). Механизмы движения по регистрам не затронуты. Типовые комплексной.

Как вариант. Попробуй все доки перекинуть в типовую какой нибудь обработочкой типа ExImDocs. Если на типовой с этими данными все прокатывает, значит переделки виноваты. Сузишь круг поисков.

Ну что, попробовала программно открыть период?

Почему попробоваЛА? В видно, что программно при начале работы системы

Тоже самое?

да

Попробуй на копии поиграть настройками регистров.

ну, в общем есть смысл попробовать, может быть объединением с типовой с "деградацией"

каким образом? период остатков? или еще что?

Есть еще предыстория. 18.01.06 поднял конфу с 459 до 460. Как раз в 460 прошло много изменений по доку Формирование книги. При переходе с 3 на 4 месяц база упала. Обнаружил, что перепроводили доки Форирования книги за 2005 год как раз в 3 месяце. Взял копию до перепроведения доков, перекачал туда по ХМЛ более поздние доки, все хорошо. В 4 месяце снова перепровели Формирования книги за 2005 год. Этой же датой все снова упало.

Прости, не догнал. (Пьян немножко, мне на пальцах) :-)

все делается на копии, даже на нескольких. Вообще вопрос, если в файлах регистров осмысленная информация, то что может так фатально влиять. Это ведь чисто формальный, стандартно предопределенный процесс расчета остатков на основании текущего состояния остатков и движений?

приятного аппетита :)

Тут особо и не поиграешь. Ведь тут все завязано на программные модули.

да, расчет остатков стандартная процедура... не понимаю, что вы с этой базой (базами) делаете... мистика...

До тех пор как не перепроводили Формирования книги после поднятия конфы - все было пучком. Стоило перепровести доки после поднятия - приплыли.

Это не мы. Судя по всему разработчики напортачили. Все механизмы стандартные.

А причин - почему так произошло, не знаешь, да?

да в общем ничего, хочешь поглядеть? это 14 метров

Что произошло - проводили доки, или почему разработчики механизм движений изменили? :)

Нет, почему приплыли. :-)

ну не одни же вы работаете с этой поставкой... имхо рыть в конфе нет смысла... хотя может md свалился? попробуйте в демке сделать то же. 14 метров в архиве... хм... ладно, с тебя пиво :)

+65 только скажите чего точно надо делать

(65.2) Без базара. Я тоже проставлю. Только вот как на украину тебе его переслать? :))

:) спасибо, с меня... да в общем, то пощелкать ТА туда-сюда, потом провести пару доков и опять пощелкать туда сюда.

мылом примешь? тогда через пол-часа сброшу

шучу я :) просто днем трафик дороже, выложи, а я вечером качну (после 23-00) да, щас придумаю на какой ящик :)

можно слать ответом

ок туда позже кину, только скажа адрес, можно мне на мыло

уже

ага, получил, вечером отвечу

переименованный в .ex_ rar подойдет? или встроенный хз зип? 7зип у меня нету

пардон встроенный в хр

лучше наверное зип, а то на рар жаловались (сам не сталкивался)

Хорошо, встроенный в хр зип