Добрый день.
Стоит задача перепровести документы в УТП за три года, в месяце документов +- 20 000
В тестовой базе за сутки идет не больше пары месяцев. В рабочей пока даже не думал как это все запускать - скорее всего по ночам, но там тоже есть какие-то регламентные задания, которые нужны.
Есть такой ньюанс - что впринципе, перепроведение нужно только по регистру бух. учета и по одному регитстру сведений.
Качал с инфостарта обработку, которая проводит документы по определенным регистрам, пытался использовать её, но в скорости проведения только потерял.
Вот думаю может сделать у документа реквизит по типу как ОбменДанными и в модуле анализировать его значение, если Истина проводить только по бух. учету, у всех документов стоит "Не удалять движения автоматически"
Будет ли реальный прирост по скорости проведения документов? Или может есть другие способы ускорить. Вобщем жду любые советы от знающих людей...

(0) ну так меняй сами движения

УТП/// такое тоже есть?

Попробуй разделить документы на группы и в разных потоках фоновыми запустить (только контролируй загрузку процессора и лишних заданий не запускай)

(0)Если это та обработка, про которую я думаю, то она проводит по всем регистрам, а ненужные потом откатывает)) Если изменения очевидны, проще и быстрее будет менять напрямую регистры, без перепроведения.

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

(0) Железо какое?

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

У тебя нет гарантий корректности результата, если ты будешь писать результаты перепроведения только по одному регистру. Все зависит от алгоритмов проведения. Скорее будут гарантии некорректности. Лучше перепроводить все как положено.
Но "перепроведение трех лет" звучит как очень стремная задача. Очень часто "вылезшие кривульки" прошлых периодов бухгалтера равняют другими "кривульками" в периоде текущем. При перепроведении все это гавно всплывет на поверхность, а пальцами будут тыкать в тебя. Поэтому сначала полностью перепроводишь копию и только когда бухи дадут добро на полученный результат, начинай перепроводить рабочую. Иначе уже первый перепроведенный месяц может привести к "все пропало, верните взад".
Если же про ускорение проведения, то такой совет дам.
При перепроведении "глубоким" задним числом много ресурсов тратится на пересчет итогов регистров будущих периодов. Как минимум, нужно попробовать сделать так: откатываешь итоги всех регистров на первый месяц, который перепроводишь, перепроводишь этот месяц и потом рассчитываешь итоги следующего месяца. И так помесячно идешь дальше. Другие способы ускорения скорее аппаратные. Всякие супер-мега-сервера с рам-дисками. Как минимум, можно попробовать в рам повыносить темпы и логи. Ессно, на "дышащем" продакшене логи в рам выносить нельзя.

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

я бы курнул обработку проведения по этому документу и выкинул бы из нею строки которые записывают движения не нужных тебе регистров. А тех которые нужны оставил.
Потом естественно вернул все назад.

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

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

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

(12) Эээ нет.
Не в курсе конкретного случая ТС но часто например возьмем пересорт по партиям для номенклатуры.
Какой смысл перепроводить документы где нет товара/номенклатуры по которому возник пересорт?

(0) Отчетность за три года тоже будете пересдавать?

(14) Сверить надо и корректировку подавать если что, это как бы по правилам/законам.

(0) Сделай как в ЕРП.
Перед записью движений сравнивай их с имеющимися в регистре и если они равны, не записывай ничего (доработка конфы).
Другие советы дать, не зная вашу базу, сложно.

(16) не такого в ЕРП

(0) видится два способа:
1. сделать копию базы, перепровести нужные документы, через план обмена выгрузить движения по нужным регистрам и загрузить в рабочую
2. начало как в п.1, но синхронизировать движения SQL запросом. Быстрее, но сложнее в реализации и расходится с лицензионной политикой.

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

Тьфу, не в ту степь съехал. Ну и фиг с ним :)

(19) Ну дык я сразу сказал что тупо берем железку пошустрее и фигачим в лоб.
Сча новые i3-8350k 4-х ядерные и легко берут 5ГГц на воздухе, к нему в пару PCIe NVMe SSD, туда файловую базу и вперед.

(21)+ Оперативки 32 гига не забыть только

(21) В принципе, файловая на SSD - это хороший вариант для ускорения перепроведения. Но только до определенного предела. Но попробовать стоит.

У ТС объемы как раз пограничные. То ли выгорит, то ли нет.