Вопрос по перепроведению

здравствуйте! помогите пожалуйста! существует следующая проблема: при перепроведении документов сначала перепроводятся документы с самого раннего изменённого документа до ТА, а потом почему-то начинают цепляться какие-то старые данные. Это приводит к тому, что время перепроведения может увеличиться в среднем на час (бывало и больше). Подскажите пожалуйста с чем это связано и как это можно обойти?<br>заранее спасибо =)

стесняюсь спросить, а в какой конфигурации работаете?

...и чем перепроводите?

1С Предприятие 7.7 Астор:Торговый дом

перепроведение выполняется стандартной обработкой

"Для платформы 7.7 с компонентой "оперативный учет":<br>"сначала перепроводятся документы с самого раннего изменённого документа до ТА" - судя по всему перепроведение идет в режиме "восстановление последовательности".<br>"почему-то начинают цепляться какие-то старые данные" - это значит, что идет проведение документа оперативного учета, позиция которого не совпадает с позицией точки актуальности и движок запускает алгоритм расчета остатков. Поэтому я обычно перепровожу документы чуть по другому. Получается быстрее, не смотря на то, что проводятся при этом и документы, не входящие в нужную последовательность:<br>меню: операции-проведение документов-документы-проведенные документы (ставим везде галочки)-Провести. При этом диапазон проведения определяем "вручную", подсмотрев на позицию последовательностей в закладке "последовательности".<br><br>В чем разница?<br>В том, что существует четыре (!!!) способа проведения документов оперативного учета. <br>Провести(<Режим>,<Знач>)<br>Параметры: <br><Режим> - необязательный параметр. Число: 0 - проводить документ без сдвига ТА; 1 - проводить непроведенный документ реальным временем (со сдвигом ТА); 2 - перепроводить проведенный документ реальным временем (со сдвигом ТА); 3 - проводить любой (непроведенный, проведенный) документ реальным временем (со сдвигом ТА). Значение по умолчанию - 0.<br><br>Разница для непосвященного целовека почти неуловима, но как факт - проведение с Режим=0 делается дольше.<br><br>P.S. Сумничаю. Расскажу как оно устроено на уровне платформы. Может кому будет интересно. Рассмотрим подзадачку. Идет проведение документа на списание чего нибудь (например, обычная реализация). Чтобы узнать на какую сумму списывать и достаточно ли вообще товара в наличии необходимо рассчитать его остаток. Как это делается? Берем все все документы прихода, берем все все документы расхода... Из прихода вычитаем расход, вот и получим нужный нам остаток. Вот если бы программа делала так, то проведение каждого документа и формирование отчетов занимало бы огромное количество времени! Поэтому реализовано не так, а более грамотно. Программа формирует "вспомогательные" слои с остатками, которые пользователь не видит, но они есть в таблицах базы. Когда мы выполняем нашу подзадачку, то делается все именно так, как я написал, но не от "начала времен", а от ближайшего вспомогательного слоя с остатками. В оперативных итогах (7.7) такие слои сформированы на конец каждого месяца. Поэтому, например, если мы проводим наш документ 5 мая 2009 года, то движок обратится к остаткам на конец апреля, переберет все документы от начала дня 1 мая и по позицию текущего документа и выведет остаток. Но! Для еще большей оперативности в программу введен еще один (!) вспомогательный слой с остатками. Это слой называется "точка актуальности" и он является плавающим. Точке актуальности соответствует какая то позиция в шкале времени (почти всегда это документ, про иные ситуации писать не буду, чтобы голову не морочить). Так вот, проводя какой то документ следующим за тем, которому соответствует слой "точка актуальности", мы не заставляем платформу вычислять остатки вообще! Они уже лежат в слое "точка актуальности", они просто берутся готовыми и все. При этом точка актуальности смещается на новый проведенный документ (то есть, вспомогательный слой с остатками корректируется на движения проводимого нами документа). Вывод: работая в реальном режиме времени (не проводя документов "задним" числом и "в будущем") мы имеем наивысшую производительность механизмов проведения документов, так как все они станут брать сведения об итогах из этого плавающего слоя. Теперь, я надеюсь, понятно почему потоковое проведение с сдвигом ТА на проводимый документ работает быстрее. Еще хочется сказать о компоненте "бухгалтерский учет". Там подход полностью идиентичный за исключением того, что там вспомогательные слои сформированы на конец каждого квартала и нет плавающего слоя "точка актуальности".<br>О проведении документов будущим временим особое слово. Если мы сделаем так, то ТА уйдет вперед и получится, что все текущие документы станут проводиться, находясь в позиции "до точки актальности", задействуя механизмы расчета остатков, поэтому проводиться будут долго. Не проводите документы будущим временем! Просто создайте его и запишите в базу, а проведете, когда время придет.<br>Установка нового периода "бухгалтерских итогов" и "оперативных итогов", о которых периодически просит программа - это и есть формирование пользователем вспомогательных слоев с остатками.<br>Еще скажу о "природе" одних граблей, которые иногда пользователи имеют. Пусть пользователь проводит "задним числом" документ от 17.11.2008 г. в конфигурации с компонентой "оперативный учет" в то время, когда сегодня 05 мая 2009 г. При его проведении платформа должна будет откорректировать вспомогательные слои "на конец ноября 2008 г.", "на конец декабря 2008 г.", ... "на конец апреля 2009 г.". Если в момент проведения пользователю надоест ждать и он выключит компьютер или произойдет отключение электроэнергии, то вполне реальна ситуация когда часть слоев окажется откорректированной, а часть нет (почему разработчики не выполняют задачу в режиме единой транзакции, не знаю, возможно, для того, чтобы память не перегрузить). Поэтому потом при входе в программу мы, конечно, переиндексируем таблицы базы, но индексы никак не исправят получившуюся проблему. Визуально проблема выглядит так: формируем отчет за декабрь 2008 года, остатки на конец видим одни, формируем за январь 2009 года, остатки на начало видим иные. Причина - вычисление остатков идет от разных вспомогательных слоев, которые сформированы некорректно из за аварийного завершения работы программы. Рецепт - пересчет итогов (бухгалтерских в компоненте "бухгалтерский учет", оперативных в "оперативном учете")<br>"

спасибо за интересную информацию!<br>однако всё-таки я не могу понять почему если период редактирования закрыт, допустим, до 1 мая 2009 года, почему может что-то цепляться за 2007, 2008 год? о_О <br>ведь там документы не меняются. и, получается, необходимости перерасчёта остатков не возникает.

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

итак. цепляются "Полученные счёт-фактуры" за 31.10.07. Причём даже если перепроведение делать повторно! при этом текущие документы не перепроводятся, а вот эти СФ цепляются и идёт какой-то пересчёт остатков<br><br>конфигурация 7.70.025 <br>модуль "магазин"<br>по поводу доработок - проблематично сказать. но вроде ничего именно здесь не меняли<br><br>

7.70.025 - это релиз платформы. что такое модуль "магазин" я тоже не знаю, но примерно понял куда смотреть.<br>Итак, смотрим в Торговля и склад, релиз 7.70.956<br><br>С недавнего (относительно) времени наши законодатели придумали, что книга покупок и продаж должны формироваться не с группировкой сведений по периоду регистрации, а по периоду действия с порождением понятия "дополнительные листы книги покупок (продаж)". Вероятно проблемы связаны с этим. Во всяком случае, формирование отчета "книга покупок" или "книга продаж" с доп.листами теперь идет жуткое количество времени.<br>Но все таки! При проведении документа какого вида вы видите обращение к "с/ф полученным" за старые года?