Перенос накопленных учетных данных из редакции 1.6 программы "1С:Бухгалтерия предприятия 8". Переход на редакцию 2.0

Ссылки по теме:

1. О выпуске редакции 2.0 прикладного решения "Бухгалтерия предприятия"
2. Переход на редакцию 2.0
3. Здесь изложен оптимистичный сценарий, но тоже может пригодиться.

В ссылке по теме №3  в картинках изложен традиционный сценарий перехода на новую редакцию программы "1С:Бухгалтерия предприятия 8". В двух словах его принцип: запускается программа в новой редакции 2.0 с пустой информационной базой, из нее открывается рабочая информационная база в старой редакции, выполняется выгрузка данных во временный файл, затем загрузка из временного файла в новую базу.

Отсюда становится понятной первая проблема: если вы работаете в старой редакции на платформе "1С:Предприятие 8.1", то и в новую редакцию можно перейти только на платформе "1С:Предприятие 8.1", поскольку открыть старую базу на платформе "1С:Предприятие 8.2" невозможно. Визуально это выглядит так: если новая редакция работает на платформе "1С:Предприятие 8.2", то старую базу в списке доступных информационных баз вы просто не увидите. Значит нужно либо конвертировать старую базу на платформу "1С:Предприятие 8.2", либо устанавливать новую редакцию на платформе "1С:Предприятие 8.1".

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

Этап 1. Запускаем рабочую информационную базу в старой редакции 1.6, теперь уже не важно на какой она платформе "1С:Предприятие 8.1" или "1С:Предприятие 8.2". Используем обработку "Универсальный обмен данными в формате XML" (МЕНЮ - СЕРВИС - ПРОЧИЕ ОБМЕНЫ ДАННЫМИ). Указываем файл правил обмена - переноса данных из редакции 1.6 в редакцию 2.0 (см. рис. 1). Это ключевой момент, о том где взять правила обмена, чуть ниже. Указываем в какой файл выгружать данные (любое имя в любом каталоге). Параметры выгрузки и настройку выгружаемых данных оставляем неизменными. О них поговорим позже.

Рис. 1 Так выглядит окно выгрузки данных из редакции 1.6

Период выгрузки. Заслуживает того, чтобы на нем остановится подробнее. По умолчанию (как на рис. 1) переносятся остатки на 1 января 2010 года и все хозяйственные операции 2010 года. Можно перенести остатки на любую дату и соответственно операции за любой период, т.е. можно перенести и всю накопленную рабочую базу целиком, все ее операции. Вопрос только в том, насколько перенесенные данные, прежде всего документы конечно, будут работоспособны в новой редакции 2.0. Формально новая редакция не поддерживает хозяйственные операции до 2010 года. К этому нужно быть готовым. Дело в том, что переносятся не движения документов, проводки например, а сами документы, т.е. их содержание, а движения документов появляются уже в новой базе как результат проведения перенесенных документов. Поэтому движения документов в новой базе (по старым операциям до 2010 года) не всегда будут совпадать с движениями в старой базе. В частности это относится к операциям по учету основных средств. Но если вы готовы, как шутят программисты, поработать напильником, то вперед и с песней.

Где взять правила переноса данных из редакции 1.6 в редакцию 2.0. Запускаем программу в новой редакции 2.0. Открываем справочник "Конвертации из информационных баз предыдущих версий" (см. рис. 2). Далее находим правила "ACC16_20", это и есть правила переноса из программы "1С:Бухгалтерия предприятия ред.1.6". Жмем кнопку "Записать файлы конвертации на диск" и указываем куда сохранить правила.

Рис.2 Сохранение правил переноса данных в файл.

Этап 2. Запускаем пустую информационную базу в новой редакции 2.0, опять же не важно на какой она платформе "1С:Предприятие 8.1" или "1С:Предприятие 8.2". Выбираем вариант "Загрузить данные из файла" и указываем файл, в который делали выгрузку (см. рис. 3).

Рис.3 Выбор файла для загрузки данных

Можно использовать обработку "Универсальный обмен данными в формате XML" (МЕНЮ - СЕРВИС - ПРОЧИЕ ОБМЕНЫ ДАННЫМИ). Указываем файл для загрузки (см. рис.4) - тот же, в который только что делали выгрузку, нажимаем кнопку "Загрузить данные".

Рис. 4 Так выглядит окно загрузки данных в редакцию 2.0

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

Попробую резюмировать: описанный здесь способ переноса данных дает ряд преимуществ, таких например как независимость от платформы. Исключается возможная проблема доступа к информационной базе - источнику. Я не стал подробно на этом останавливаться, но такая проблема тоже возможна (см. рис. 5).

Рис. 5 Одна из возможных ошибок переноса данных

Возможна и такая ошибка как на рис.6. Здесь понятно, что делать - обновить релиз конфигурации базы-источника. Это нужно сделать независимо от способа переноса данных.

Рис.6 Ошибка, связанная с релизом конфигурации базы-источника

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

Описать все возникающие при переносе данных проблемы не представляется возможным, но некоторые наиболее критические ошибки я постараюсь осветить. Начну с того, что в правилах переноса от 07.12.2010 (!!!) в ПКО "ОперацияБух" в обработчике события "Перед выгрузкой" используется очень неэффективный запрос к данным. А именно, в алгоритме "ПолучитьПроводкиДокумента" (Алгоритмы.ПолучитьПроводкиДокумента) в запросе используется конструкция:

	 ИЗ

	 РегистрБухгалтерии.Хозрасчетный.ДвиженияССубконто КАК ХозрасчетныйДвиженияССубконто

	 ГДЕ

	 ХозрасчетныйДвиженияССубконто.Регистратор = &Регистратор

Такой запрос с отбором по регистратору, т.е. по одному документу, выполняется по времени так же долго как и запрос по всей таблице ДвиженияССубконто, т.е. по всем документам (не только "Операция"). В зависимости от размера информационной базы это время может составлять от нескольких секунд до нескольких минут. Но поскольку таких запросов при переносе будет столько же сколько документов "Операция", то общее время выгрузки документов "Операция" может нарастать катастрофически.

Что можно сделать в такой ситуации:

1. Исключить при переносе документы "Операция", перенести их отдельно или вручную.

2. Использовать для переноса документов "Операция" более ранние правила переноса (или более поздние - ошибка наверняка будет исправлена).

3. Исправить сами правила переноса. Указанную конструкцию в запросе нужно заменить на:

	 ИЗ

	 РегистрБухгалтерии.Хозрасчетный.ДвиженияССубконто(, , Регистратор = &Регистратор) КАК ХозрасчетныйДвиженияССубконто.

И аналогичную в том же запросе

	 ИЗ

	 РегистрБухгалтерии.Налоговый.ДвиженияССубконто КАК НалоговыйДвиженияССубконто

	 ГДЕ

	 НалоговыйДвиженияССубконто.Регистратор = &Регистратор

заменить на

	 ИЗ

	 РегистрБухгалтерии.Налоговый.ДвиженияССубконто(, , Регистратор = &Регистратор) КАК НалоговыйДвиженияССубконто.

Итак, на конец 2010 года возможны три различных сценария по переносу данных в редакцию 2.0.
1. Перенести остатки на 1 января 2010 года и все операции 2010 года документами. Плюс такого подхода в том, что перенос будет однократным, следовательно исключаются ошибки, связанные с изменениями данных уже после переноса. Работа ведется всегда только в одной базе: до переноса в редакции 1.6, после переноса данных - в редакции 2.0. Данные 2010 и 2011 года будут находится в одной базе. Минус - перепроведение документов за целый год и вероятное несовпадение оборотов, а точнее в более общем виде всех движений документов, в старой и новой базе;
2. Перенести остатки на начало 2011 года в конце декабря или начале января и какое то время работать параллельно в 2-х базах. Минус - неизбежны повторные переносы данных, придётся вручную синхронизировать базы. Данные 2010 и 2011 года будут находится в разных базах. Плюс - не нужно перепроводить существующие документы, простота и время переноса;
3. Перенести остатки на начало 2011 года после отражения всех операций 2010 года или даже после годового отчета, т.е. уже в 2011 году, а операции первого квартала 2011 года перенести документами и перепровести. Минус - операции 2010 и 2011 года будут в разных базах, работа в 2011 году в старой редакции. Плюс - однократный перенос, перепроводка документов за более короткий период.

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

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

А вот второй вариант требует особого внимания, поскольку все чаще звучит вопрос: "Интересует, будут ли проблемы при повторном переносе если клиент будет редактировать в промежутке между переносами справочники в редакции 1.6 или 2.0"? Отвечаю: "Да, будут". Рассмотрим.

Будем использовать для тестового переноса данных демо-базу программы "1С:Бухгалтерия предприятия 8" в редакции 1.6. Выполним перенос данных за 2010 год как описано выше. А затем, уже после переноса, отразим операцию получения услуг от нового (это важно!) поставщика (см. рис.7). Эти услуги оказаны в декабре, следовательно они изменят сальдо по счету "60.01" на конец года.

Рис.7

Предположим, организация "Торговый дом "Комплексный" оплатила поставщику оказанные им услуги в январе 2011 года, следовательно эту операцию следует отразить в новой базе, что мы и сделаем (см. рис.8). Введем в новой базе нового поставщика с тем же ИНН, с тем же наименованием и даже  код у нас получился тот же. Что кстати не всегда возможно, просто в нашем случае мы добавляем и в новой и в старой базе нового контрагента сразу после переноса, поэтому новому элементу справочника присваивается очередной номер и он в данном случае совпадает. Еще раз подчеркну, если бы например в новой базе мы успели ввести к этому моменту других новых контрагентов, то для контрагента "Новый поставщик услуг" код в старой и новой базах уже не совпал бы.

Рис.8

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

Рис.9

Несколько изменим ОСВ по счету "60", не будем формировать отчет по субсчетам (см. рис.10). Теперь хорошо видно, что контрагентов с одинаковым названием у нас два. Второй появился в результате повторного переноса. Обратите внимание, по остальным контрагентам, перенесенным во время первоначального переноса данных, никаких проблем не возникло. Почему же возник двойник у контрагента "Новый поставщик услуг"? Открою маленькую тайну: я в новой базе указал для него КПП, а в старой базе этот реквизит был пустым. Поясню, как переносится справочник. Сначала ищется объект (эл-т справочника) в приемнике по внутреннему идентификатору источника, поэтому по УЖЕ ПЕРЕНЕСЕННЫМ объектам проблем не возникает. Но если в приемнике по внутреннему идентификатору объект не найден (как в нашем случае), то дальше поиск пойдет по реквизитам, н-р для справочника "Контрагенты" это код, наименование, ИНН и КПП (ну и признак того, что это группа - несущественно). Таким образом, в нашем случае соответствие по реквизитам установить не удалось из-за несоответствия КПП, поэтому был создан новый элемент справочника.

Рис.10

Что такое внутренний идентификатор объекта. Он присваивается при создании любого объекта (элемента справочника, документа), и он уникален, т.е. при создании в разных базах двух "одинаковых" объектов - одинаковых по жизни, их внутренние идентификаторы никогда не совпадут. При первоначальном переносе объекты в новой базе создаются и им присваивается внутренний идентификатор объекта-источника. Поскольку этот идентификатор никогда  ни при каких обстоятельствах не изменяется (пользователем), это и обеспечивает повторный перенос без проблем. А вот с новыми объектами, созданными уже после первоначального переноса, проблему я описал. Правила переноса различных объектов - различны, чаще поиск в новой базе производится для справочников по коду и наименованию, для документов по дате, номеру и организации, но далеко не всегда это так. Не зная этих правил, невозможно следить за синхронизацией информационных баз.

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

© Борис Балясников, декабрь 2010г.