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

Мне задали вопрос - а возможно ли в семерке какой-нибудь обработкой создать движения по регистрам, с указанием документа-регистратора? Ну, типа, сами проведенные документы движений не делают, а вот обработка - делает.
У меня в голове возник только 1 вариант - но не обработкой, а такой: сохранить "куда-то" движения в исходной базе, а при проведении каждый документ в целевой базе ищет в этом "куда-то" движения для себя, и если находит - делает их, а не то, что указано сейчас в модулях проведения. Минус в том, что придется переделывать все модули проведения, и начальство хочет все же обработкой это сделать. Поэтому, допуская, что я могу не знать просто о таком варианте, спрашиваю здесь.
Напоминаю - база 7.7, не восьмерка.

Перенести движения в точности надо для того, чтобы отчеты, работающие по регистрам, совпадали в исходной и целевой базах.

Можно. При некоторой правке конфигурации.

Что-то в стиле https://infostart.ru/public/79515/

(2) да можно и без правки.
Но в целом да, ты прав, обезъянкам лучше с гранатой...

Урбд переносит движения как есть. Мд шник можно менять, если нет реструктуризации. Правила регистрации изменений можно разные.

А конвертация 2 в 7ке не может, это печально.

(0) Можно в каждом документе в модуле проведения добавить код, что при передаче туда, например ТЗ, он движения делал про этой ТЗ.

все в итоге сводится к одному: "позовите программиста"

(7) есть еще вариант. Пригласите юриста, запегистрируйте новое юрлицо и начинайте учет в ЕРП с нуля.

(3) у Ёпрст-а хорошие гранаты, качественные!

(9) это да.

автор начни с того чтобы не путаться в названиях: это не перенос, это обрезание.

(0) Вместо (2) попробуй лучше https://infostart.ru/public/102101/.
Сам пробовал, все работало нормуль ибо (3)

+12 Очепятка - ибо (9)

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

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

(15): именно. см.(15)

эмм.. в смысле (11)

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

(18) Так остатки только можно сделать, с движениями может выйти боком.

(19) нет, можно и остатки, и движения...

(19) а остатки что, не движением формируются что ли?

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

(21) а можно по разному :-) Это ж клюшки...

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

(22) об этом я и писал в (18). но это, имхо, не критично.
а если оказывается критично - то ССЗБ с такой архитектурой.

(6) (14) У меня примерно так реализовано. Проведение по заранее рассчитанным тз происходит не то, что 'не быстро', а гораздо быстрее типового.

(18): не надо плохое советовать. перетаскивание "честных" по-документных оборотов в сводные по-кстатитынесказалкакие (месячные судя по всему, "за поределенный период" в формулировке (0)) - это довольно кривой способ, который не гарантирует корректность работы с этими периодами от члова "никак" (только остатки-обороты и сохранишь, а до хренища всего еще и на документы завязано, и на их реквизиты. и на связки движей по разным регистрам. и т.д.). короче хню полную ты пособетовал - оно годится для укрупнения и свертки но не для раб.периодов.
(25): именно что критично. например с плясками вокруг сверок по-документных и зачетов с контриками - и это навскидку только.

ЗЫ: кстати никто не мешает выгрузить все движения по-документно с возможностью однозначной их идентификации - свособов море вплоть до (по-документных)+(по-регистровых) файлов с именем id документа.
и в глобальник засунуть одну экспорт-функцию типа ПопробоватьВосстановитьСохраненныеДвижения, которая получает на входе документ, читает движения и если они есть - двигает что надо и как надо и возращает 1, иначе возвращает 0. а во все(!) модули проведения в самое начало вставить один и тот же код - "Если ПопробоватьВосстановитьСохраненныеДвижения(ТекущийДокумент())<>0 Тогда Возврат КонецЕсли;".
жа хоть в разовые справочники выгрузить эту беду - там вообще по-объектно дез плясок с id измерений можно, тогда вообще все будет быстрее и проще.

(27) входящие остатки - понятно, по остальным переносимым документам от даты остатков до сейчас - считываем движения КАЖДОГО ПЕРЕНОСИМОГО ДОКУМЕНТА из исходной базы и ДУБЛИРУЕМ ЭТИ ДВИЖЕНИЯ в новой. консолидации таких документов - нет.
.
"а до хренища всего еще и на документы завязано, и на их реквизиты." - ну, это и есть бяка, с которой придется смирится."
.
"и на связки движений по разным регистрам."
при переносе движений как описано - все связки сохранятся.
.
"с плясками вокруг сверок по-документных и зачетов с контриками"
с этим придется смирится при свертке на дату остатков), например, на начало 2020г. более длинные долги - редкие.
.
конечно, надо смотреть на специфику базу и от этого выбирать и дату свертки и применяемый метод переноса.

(29): не ори.
сверка взаиморасчетов по документам "Движение регистров", ага, ну-ну.
свой набор реквизитов у каждлого документа, которые много где дергаются и много зачем (особенно в упр.учете) - из "двигателей" неоткуда выдрать.
и это - НЕ "бяка", не тринди. аж стыдно от тебя это слышать а не от недоучки каког-гнибудь с опытом в полтора клиента.
"ться", блин! ну тогда можно смириться и с потерей всей нахрен аналитики - а чо гулять так гулять злопер разрешил lol
нахрена делать (в чем-то) неправильно если можно сделать (полностью) правильно? особенно если изменения в конфиге - всего в полтора раза больше чем добавить "двигатель", зато сохранится все как надо.

ну детский сад. Серёга, не ожидал подобной хни от тебя. прикинь ты такой пильнул WMS с палетной оптимизацией, подкачками - а тебе "ну мы свернем на фуззи-принципе, пусть там где есть будет по 1 щтуке признае наличия - а дальше исправим как-нибудь. "с этим придется смиритЬся".... фейспалм.

ЗЗЫ: и еще раз. по слогам. почему не свертка? тогда и перепроводить ничего не надо.

(30) ну я хз, что там у ТС за самописка. конечно, лучше сделать правильно, если правильно не хватает опыта/иное - то двигателем проще всего. или что-то аналогичное, типа движения по ТЗ по/в родном доке сформировать как выше кто-то описывал.
.
"WMS с палетной оптимизацией, подкачками - а тебе "ну мы свернем на фуззи-принципе, пусть там где есть будет по 1 щтуке признае наличия - а дальше исправим как-нибудь."
- ты не  поверишь! практически так и есть в последнем личном проекте (где даже не паллетный а нормальный штучный). прото тупо потому, что заказчик не сумел обеспечить наличие требуемых исходных данных и пришлось загрубить практически до того состояния что ты описал... и потом вопрос "а зачем это все в отдельной WMS базе если можно то же самое было сделать в учетной базе" ;-)

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

(33): ну а я об чом. (31) и дажн раньше в (11)

Когда-то делал для себя, для идентичных конфигураций вроде работало. Умеет переносить движения по любым регистрам. Но это давно было.
https://infostart.ru/public/96745/
Временно ломается конфигурация, потом возвращается обратно. Ничего страшного. Главное, разобраться, что происходит.

Ребят, спасибо большое за ответы, извините за задержку с ответами, проблемы были.

Как вариант у меня был как раз - записать куда-то движения подокументно, и при проведении документов проверять, если для этого документа есть записи, движения делать из них.Но мне предложили спросить на форуме, есть ли другие варианты.

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

Не свертка это потому, что изначально начальник хотела оставить в перенесенной базе 2020 год (на начало его перенести остатки, а все остальное - документами).

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

Почему КД переносит таким образом - непонятно. Я б еще понял, если в исходной было данных больше, чем в целевой. Но ведь есть и обратные ситуации; есть также несколько документов, которые совпадают, но движения по ним разные (видимо, это случаи, когда 1с вылетала, и документ сохраниться успел, а движения по нему не сделались еще?)..

Частично ситуацию исправил, отключив обработку неверно переносимой колонки в модуле проведения. Сейчас проверяю результат.

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

Как-то так. Жду комментариев...

(1) >Перенести движения в точности надо для того, чтобы отчеты, работающие по регистрам, совпадали в исходной и целевой базах.

Зачем надо чтобы отчеты в исходной и целевой совпадали?

Может все же надо чтобы отчеты были правильными по правильным движениями по регистрами?

Накатить МОД, перенести движения МОДом, убрать МОД.

(36) на ТрадиционныйКитайскийВопрос® так и не ответил...

(36) "Не свертка это потому, что изначально начальник хотела оставить в перенесенной базе 2020 год" - какая разница на какую дату сворачивать?) Это лишь "прихоть" конечного пользователя, не более.

Я тебе еще в (12) указал на рабочий инструмент для переноса доков с движениями "как есть"

(40) а зачем вообще переносить, если можно не переносить, а убирать ненужное?

(41) Видимо, убирать гораздо больше. Мне отсюда не видно - это у (0) надо спрашивать

(42) "ломать - не строить"©

Скопировать базу и грохнуть все лишнее будет правильней. Хотя надо разобраться, что автор имеет ввиду из глючной базы.
Если база самописка с кучей доделок то и типовые обрезания нужно юзать с умом.
(42) у того же Ёпрст есть обрезалки которые режут быстро и качественно не взирая на объем обрезаемого.

(0)Сделать общий реквизит "ручная корректировка". Если он установлен, то при перепроведении документа ничего не делать. Единственный минус, если какой-то дятел решит отменить проведение, то вся красота накроется медным тазом.
Есть ещё другой способ. Загружать и проводить "как есть", а разницу потом внести корректировками регистров. Не так красиво, но более надёжно.

База в неконсистеном состоянии. Что-то там годами переписывалось криворукими говнокодерами, "1с вылетала, и документ сохраниться успел, а движения по нему не сделались еще", пёс его знает, что ещё. Простое перепроведение поменяет старые движения до неузнаваемости. Любая попытка как-то это упорядочить - обречена. Какой смысл перетаскивать хаос из одного угла в другой? Не трогайте это дерьмо, начните заново с аудитом и ревизией. Хотя - Hans get ze flammenwerfer!!!

(46) "Что-то там годами переписывалось криворукими говнокодерами","Какой смысл перетаскивать хаос из одного угла в другой?"
ну, собствено, очередной оный - перетаскивает то самое из одного угла в другой, попутно  добавляя своего...

(37) Затем, что это отчеты по закрытым периодам. Соответственно, нельзя их изменять. А не получается, если просто перенести документы и провести их.

(39) какой?

(40) Свертка это в пределах одной базы, разве нет? У нас база повреждена, поэтому переносим остатки и документы в другую базу. Это уже, КМК, не свертка. Впрочем, хоть горшком назови(с)..
про (12) начальству сказал, пока решили попробовать наш вариант, перенести остатки на начало года, перенести документы (выполняя в них движения по двум основным регистрам, по которым нет отличий от исходной базы), и перенести документы за последний незакрытый месяц (и за текущий), делая все движения (перед этим перепровести все документы в исходной базе в незакрытом месяце).

(41) Основная проблема - база повреждена. ТиИ выдает кучу ошибок. Создавал тут тему, советы оттуда не помогли. Принято решение перенести остатки и документы за определенный период в новую базу. Так-то саму базу регулярно сворачиваем, когда слишком увеличивается..

(44) Не вариант. Копирование базы копирует и ошибки в ней. База в свое время была написана полностью с нуля. Обработки свертки базы уже давно есть, но в данном случае они не помогают. Причем, если я вручную исправляю ошибки (например, ругается на некорректные ссылки (на справочник Продукты) в табл. части документов) - потом появляются ошибки уже в других документах, в которых их не было ранее. Что там с базой дальше будет я ХЗ, но страшно ее оставлять в таком состоянии. База производственная, если она рухнет, то будет ПП.

(45). Изначально какие-то движения в базе должны быть созданы при переносе документов. А они, бывает, не совпадают с движениями в исходной базе (хотя в целевой при этом движения и соответствуют текущему содержимому табличной части, т.е. они "правильные"; но надо, чтобы они совпадали с движениями в исходной базе - чтобы совпадали отчеты, которые работают по движениям).
Второй способ конечно возможен. уже и документы для корректировки в базе есть - но тогда полетят отчеты.

(46) Ну вот уже и оставили 20й год в старой базе, пускай там отчеты смотрят, надеюсь, что 21й год не будет иметь проблем. И еще, просто начать с аудитом вряд ли получится, база производственная, это весь завод останавливать неизвестно на какой срок. Поэтому приходится переносить часть документов по-любому.  В надежде, что в переносимом периоде не будет проблем. Изначально, как сказал, собирались перенести с начала 20 года, сейчас уже согласны только на 21й.

Офф. Еще попутно такой вопрос возник - про конвертацию данных 2. Я не понимаю, почему при переносе табличной части некорректно переносится 1 реквизит в двух типах документов? "ПартияПуск" он называется, содержит строку, в которую перенесли содержимое списка значений (коды элементов справочника партий). Причем, если 1 раз перенести, это будут одни документы. Если повторно перенести - уже другие документы.
Причем, проблемы почти всегда только с этим реквизитом, в двух видах документов, где он используется. В остальном - несколько документов (проверял на одном месяце пока) с неверными движениями в исходной базе.

(48) вопрос - "анахуа?"®
ТИИ можно не делать.  я за последние 15 лет с клюшками ни разу не делал - ибо не дождался бы окончания, да и не дали бы мне столько времени, ибо 24/7/364
"база повреждена" - слишком уж "бесформенное" определение. что повреждено-то?

(49) "бесформенное" определение. что повреждено-то?
Фсё!

(50) машина сломалась!©ералаш

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

(49) Т.е. вы не знаете, есть ли какие-то проблемы в базе, и не боитесь, что она в определенный момент может полететь? Или вы считаете, что механизм ТиИ добавлен 1с в программу "просто так", он глючный, и вообще смысла не имеет?
А что касается 24/7 ит.д. - так я не думаю, что у вас файловая база, а скульную можно и продублировать в копию, и ее уже протестировать. Кто мешает?

Какие именно ошибки были?
Ну, разные. Часть я уже исправил. Остались вот такие сообщения:
"Проверка содержания справочников. КомплектацияМ. Элемент     1. Изменено подчинение" (Справочник подчинен справочнику материалов, и его содержимое критично для работы).
"Проверка содержимого документов. ТребованиеНакладнаяПроизводство. Номер ТМ011461. Реквизит Продукты в строке 44. Неразрешенная ссылка. Тип - Справочник Продукты"
Примечание: Если в глючных документах очистить данный реквизит, и сделать ТиИ повторно - глюки проявятся в других документах.

(52) ну собственно, на таком варианте пока и остановились, пока тестирую на копии.

(53) я весьма неплохо знал свою базу. И совершенно не боялся, что она может полететь. Потому, что я имел несколько сценариев нарушения работы, и реакции на эти нарушения.
ну, в общем, равно как знаю внутреннее устройство базы, и способен вычислить указанные ошибки без ТИИ.
Механизм ТиИ лействительно глючный (добавлен не "просто так", но в прошлом веке, для небольших баз, и с тех пор не дорабатывался), и убил людям не одну базу (и даже не десяток).
Да, база была серверная - но и файловую можно скопировать. Даже если ошибка не в файле, а на диске.


"Если в глючных документах очистить данный реквизит, и сделать ТиИ повторно - глюки проявятся в других документах." - прежде, чем что-то делать - надо думать. "Почему появился", "есть ли подобные ошибки", "есть ли данные, откуда восстановить потерю" (ну вот 100%, данную ошибку что можно восстановить из движений регистра, а не чистить), "когда появился". А ТиИ не думает, оно шашкой машет. Т.е "инструмент для дураков".

свертка.

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

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

(56) структура клюшек разжевана от и до. впрочем, ладно.
почему "свертка не помогает"?
имхо, вам поможет (ну вот прямо с 99% вероятностью) просто полная реиндексация.

(58) потому что скулем скопировал базу в тестовую. ТиИ выдала ошибки. свернул. ТиИ выдала ошибки.

(58) Что вы имеете в виду под "полной" реиндексацией? Она может быть частичной? Если что, в ТиИ я реиндексацию делал.

(60) удалить индексы и реиндексировать.
индексация "при запуске" или в ТиИ индексы заново не создает (вот, кстати, один из косяков ТиИ).

(59) так база файловая или сиквельная?

(62) Рабочая база на скуле. Тестировал тоже на скуле.

(63) тогда перестроить индексы так:
DECLARE @MyTable varchar(32)
DECLARE @MyIndex varchar(32)
DECLARE MyCursor CURSOR FOR
SELECT o.name, i.name
FROM sysobjects o INNER JOIN sysindexes i ON o.id = i.id
WHERE (o.xtype = 'U') AND (INDEXPROPERTY(i.id, i.name, 'isStatistics') = 0) AND (i.dpages > 0)
ORDER BY o.name, i.indid
OPEN MyCursor
FETCH NEXT FROM MyCursor INTO @MyTable, @MyIndex
WHILE @@FETCH_STATUS=0
BEGIN
PRINT 'Реорганизация индекса '+@MyIndex+' из таблицы '+@MyTable
DBCC DBREINDEX (@MyTable,@MyIndex)
--DBCC INDEXDEFRAG (0,@MyTable,@MyIndex)
FETCH NEXT FROM MyCursor INTO @MyTable, @MyIndex
END
CLOSE MyCursor
DEALLOCATE MyCursor

(56) и Что произойдет с "Проверка содержимого документов. ТребованиеНакладнаяПроизводство. Номер ТМ011461. Реквизит Продукты в строке 44. Неразрешенная ссылка. Тип - Справочник Продукты"при  переносе в чистую базу? Перенесется продукт с не заполненным этим полем. И по новой начнет плодить ошибки. нужно разбираться что в этом поле должно стаять и пройтись по справочник обработкой и правильно по заполнять эти поля. А так вы тупо копируете ошибки из базы в базу и добавляете новые.В большинстве случаев это 2-3 ошибки возникшие в связи с бездумным изменением структуры базы которые лечатся написанием 1-2 обработок для исправления заполнения нужных полей.
Второй вариант начинать базу с нуля писать новую отчетность которая собирает отчет из 2 баз до какой то даты тянет данные из старой базы после какой то из новой. Но опять же тупо переносить справочники из 1 базы в другую нельзя нужно делать перенос с контролем что все поля нужные для корректной работы программы заполнены. А это прощай универсальные обмены и привет индивидуальные обмены для каждого элемента базы.

Полный журнал не по порядку вот пример как чел получил гемор на ровном месте просто применив ТИ.
СКЛ имеет механизмы поддержания целостности структуры БД на порядок лучшие чем может предложить ТИ.

(65) Пускай перенесется с незаполненным полем. Но там будет пусто, а не левая ссылка на несуществующих элемент справочника.
Или вы думаете, что КД будет в новую базу переносить документы с такими левыми ссылками?

(67) ЕСли делаем базу и собираемся в ней дальше работать она должна содержать полную 100% проверенную информацию. Кто его знает что было в том поле может там была ссылка на технологию типа варить рыбу фуго при температур 90% 45 с. и из-за отсутствия этого комментария куча человек траванется. Будет выпущенная бракованная продукция на нацать миллионов. Или в себестоимость не посчитается левая цифра и завод будет полгода продавать продукцию в убыток. Кто это потом будет компенсировать.