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

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

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

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

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

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

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

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

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

Об ошибках подробнее. В практике встречаются информационные базы, в которых количество объектов, образующих остаток по счету (н-р 62), составляет несколько десятков тысяч или даже сотен тысяч. При этом достоверных остатков по счету всего несколько десятков или сотен, т.е. в тысячу раз меньше. Ясно, что переносить весь этот мусор в приемник не имеет смысла. Тогда нужно отказаться от переноса документов расчетов с контрагентами вообще, свернув остатки в разрезе контрагентов и договоров. Лучше исправить вручную сотню остатков в приемнике после переноса, чем исправлять десятки тысяч позиций. В правилах для переноса 2.0 в 3.0 для этих целей служит параметр Отказаться от переноса документов расчетов в остатках по счетам расчетов с контрагентами. При этом на каждую пару Контрагент+Договор в приемнике формируется отдельный документ расчетов с контрагентом, т.е. остаток по каждому договору записывается на одну партию. Именно это после загрузки в приемник и нужно исправить, если конечно Вы располагаете достоверной информацией об остатках по партиям расчетов. Часто описанная ситуация возникает при первоначальном использовании УСН с последующим переходом на общую систему налогообложения, но не только так.

Сравним на этом примере вариант переноса данных и свертку. При классической свертке перезаписываются остатки по регистрам, а все ненужные предшествующие дате свертки документы должны быть удалены. Но в описанном случае документы останутся в базе, ведь на них есть ссылки в остатках. При свертке никакой подмены ссылок нет. Есть в остатках ссылка на "старый" документ реализации например, значит этот документ в базе останется. При переносе остатков документами ввода остатков такие ссылки заменяются на документы расчетов с контрагентом, а документ реализации не переносится. И что еще важнее, есть возможность сократить количество позиций в остатках. Был случай, когда в формировании остатков по счету 62 участвовало 132 тысячи объектов, выгрузка продолжалась два часа. При отказе от переноса документов расчетов количество объектов сократилось до 5 тысяч, а время до полутора минут.

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

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

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

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

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

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

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

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