логотип
Главная

Рейтинг@Mail.ru

Стратегия переноса данных из БП 2.0 в БП 3.0

Начнем с того, что безусловно переход с версии 2.0 на 3.0 можно осуществить традиционным способом путем обновления конфигурации. Но не всегда это получается по разным причинам, о некоторых из которых скажу ниже. Более того, не всегда это лучший с точки зрения результата и удобный с точки зрения процесса вариант. В данной статье рассмотрим вариант перехода путем переноса данных с использованием различных обработок (правил) переноса данных. Это оптимальный с точки зрения автора способ для измененных конфигураций, для случая запущенного учета с большим количеством ошибок, а также для больших по размеру информационных баз.

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

Вот про измененные конфигурации в первую очередь и скажу. Не буду долго распространяться, почему и как возникают такие проблемы, просто приведу пример из практики (см. рис.1 и рис.2). Эти рисунки демонстрируют проблему, возникшую при переходе на редакцию 3.0, но проявляется она уже при следующих обновлениях до очередного релиза 3.0.

При обновлении измененной конфигурации до очередного релиза

Рис.1 При обновлении измененной конфигурации до очередного релиза

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

При обновлении измененной конфигурации до очередного релиза

Рис.2 При обновлении измененной конфигурации до очередного релиза

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

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

Переход на новую редакцию путем переноса данных также может быть различным.

  • Можно выгружать из рабочей базы редакции 2.0 и загружать сразу в 3.0. В этом случае никаких преобразований конфигурации не происходит. Устанавливается пустая база с типовой конфигурацией 3.0 и в нее загружаются данные. Отсутствие ошибок в конфигурации гарантировано.

  • А можно загружать в такую же конфигурацию 2.0, т.е. свернуть рабочую базу, а переход на новую версию осуществить обновлением конфигурации. Этот вариант подойдет тем, кто сомневается в правильности конвертации данных из редакции 2.0 в 3.0. В таком случае перенос данных сводится по сути к формированию документов Ввод начальных остатков, остальные объекты переносятся один в один (или вообще не переносятся а остаются неизменными) и конвертируются в 3.0 уже в процессе обновления конфигурации.

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

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

А здесь правила для переноса 2.0 в 3.0. Достоинства такого подхода описаны выше.

© Борис Балясников, последние изменения январь 2017г.

© ООО "Профи-центр", г.Бирск: тел. (34784) 4-25-50, факс: (34784) 4-25-50, icq: 565351574, 591661865, mail@profiufa.ru +18