Перенос данных из ЗУП 3.0 в ЗУП 3.0

Добрый день!

Есть база 1С: ЗУП 3.0 (3.0.25.113), данные с 2014 года. Так с этого момента сменилась много расчетчиков. В базе масса проблемных мест по расчетной части, для решения приходиться постоянно править документы в  "лохматых" года.

Принял решение попробовать перенести данные в "новую" чистую базу 3.0. С кадровыми данными вроде  через КД 2.0 (универсальны обмен) все задалось. А вот с начислениями, отработанными днями - засада .Данные пришлось вытаскивать через SQL и создавать документом "Перенос данных", но постоянно вылазят проблемы с регистрами, то один надо перетащить, то другой ... короче "не выходит каменные цветок" (


Суть вопроса ... может есть какая то "волшебная" обработка ?

PS: Я понимаю что есть штатные обработки с 2.5 на 3.0 .. но ничего не нашел из 3.0 в 3.0 (


Спасибо!  

На инфостарте есть обработка переноса данных между идентичными конфигурациями 3.0.

impuls, могу ошибаться, но перенос идентичных конфигураций, не совсем походит, так как это фактически полное копирование данных из одно ИБ в другую.
Мне же нужно сформировать правильно документы переноса данных (начислений, отпусков и т.д.) .. собственно что рекомендует 1С в случае перехода из 2.5 в 3.0 ...  

Sergey, а сформировать правильно сами исходные документы в исходной базе - не предлагать?

Тэра, буду признателен за любые конструктивные  предложения ;) .. но тему создал специально для переноса данных между конфигурациями , тут уже больше "спортивный" интерес. Вообще, до того как взялся за задачу, в моем понимании перенос виделся мне как:
1. Перенос кадровых данные сотрудников и физ. лица
2. Перенос расчет среднего заработка по всем сотрудникам, по каждому месяцу
3. Перенос фактических отработанных дней и часов  и по всем сотрудникам ..

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

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

И еще есть вопрос который не дает мне покоя, когда лучше переходит на "новый" ЗУП  .. начало года, начало квартала, начало месяца ... может вообще без разницы ??

Спасибо!

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

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

Тэра пишет: Может у меня не получается донести суть моего вопроса, но сейчас фактически  перенесено 80-90% и считает, пусть где то с косяками, которые в свою очередь решаются еще переносом какого то нового регистра или правкой данных в базе "доноре". Вот и обращаюсь за помощь на форум.

Хотелось бы получить более прозрачное, лаконичное  решение ... например смотрел перенос с 2.5 на 3.0 но не переносят 1С  все регистры подряд.  

Sergey, чтобы решить вашу задачу, надо подробнейшим образом проанализировать данные и понять, что там у вас за ошибки. Этого не сделать по форуму! И тем более бесплатно.

Тэра, очень жаль что Вы не "услышали" моего вопроса, я не прошу анализировать данные и разбираться в проблеме, для этих целей есть расчетчики. Как программист, я прошу типовой алгоритм переноса рабочих данных и минимальный список регистров для расчета.
Больше чем уверен, что в природе есть решения переноса данных в ЗУР 3.0 например из стороннего ПО по расчету ЗП ..  

Sergey, так Вы изначально поставили задачу переноса из одной конфигурации в точно такую же.  А в типовом механизме переноса из 2.5 в 3.0 есть два режима - перенос только кадровых данных и перенос также и расчётных данных (в нужные регистры), правда второй вариант 1С не рекомендует, но я пользуюсь только им. Если же переносить из "кривой" 3.0 в 3.0, то нужно точно знать какие же косяки есть в исходной конфигурации, чтобы при переносе их программно исправить. Невозможно решить такую задачу для общего случая.