Особенности перехода с 1С Бухгалтерии 2.0 на 3.0

Не так давно фирма «1С» порадовала выходом новой версии прикладного решения 1С: Бухгалтерия предприятия 3.0 и огорчила последующим прекращением поддержки версии 2.0 весной 2014 года. Чуть позже разработчики по просьбам партнеров согласились продолжить поддержку версии 2.0 в части регламентированной отчетности до конца 2014 года.

Решение является долгожданным продолжением легендарной серии бухгалтерских программ. Оно обладает принципиально новым интерфейсом (т.н. управляемое приложение), который открывает перед пользователями новые возможности: возможна работа в режиме тонкого и веб-клиента, размещение приложений в «облаке», формирование отчетов в «фоновом режиме» и другие. Помимо интерфейсных преобразований есть некоторые улучшения по части ведения учета: расширен модуль учета заработной платы, учет налогов стал более удобным и логичным.

Особенности перехода

Переход с 1С Бухгалтерии с версии 2.0 на 3.0 неизбежен для всех организаций, где используется конфигурация. Сам процесс перехода не составляет особого  труда и представляет собой простое «обновление» конфигурации на очередной релиз. Но есть и ложка дёгтя. На практике некоторых  проектов уже был получен опыт перехода нетиповых конфигураций, которым хотелось бы поделиться. Ниже будут рассмотрены проблемы и особенности, которые встречаются в конфигурациях с уровнем изменений «больше среднего». (Если у Вас типовая конфигурация, Вам подойдет инструкция  как обновить 1С Бухгалтерия 3.0)

Нужный релиз

Начнем с исходного: что необходимо для перехода? Необходимо немногое – релиз конфигурации версии 2.0, с которого можно перейти на актуальную версию. Чтобы понять, какой релиз необходим, нужно найти на сайте http://users.v8.1c.ru информацию об актуальной версии, пригодной для обновления. Например, на текущий момент актуальна версия 3.0.27.7, которая может быть обновлена с релиза 2.0.53.6.

Адаптация доработок конфигурации

Если конфигурация нетиповая, первая и самая сложная задача, которая стоит перед «внедренцами», — перенести доработки из функционала «двушки» в «тройку».

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

Здесь встречаются следующие особенности:

• Все доработки, сделанные на «обычных» формах, нельзя просто так перенести в управляемые формы. Необходимо адаптировать программный код.
• Бухгалтерия 3.0 – это по сути своей новая программа. Если, например, ранее Ваша доработка находилась в функции «РасчитатьПроцентНадбавки» в модуле документа «ПоступленияТоваровУслуг», то теперь такой процедуры может не быть вовсе. Тут встаёт вопрос о необходимости серьезного понимания и анализа каждой доработки.
• Если доработки программистов использовали типовые общие модули, с большой вероятностью «ссылки» будут потеряны: общие модули серьезно изменились: как состав их функций, так и их имена (наследие новой БСП 2.х).
• Такая же ситуация с объектами метаданных. Большое количество объектов стали «ненужными», вместо них используются другие объекты, некоторые были переименованы (например, справочник «РегистрацииВИФНС» стал называться «РегистрацииВНалоговыхОрганах»).

Проблема отраслевых «надстроек»

На текущий момент на основе конфигурации 1С: Бухгалтерия предприятия существует огромнейшее множество отраслевых решений. Эти решения зачастую устанавливаются как «надстройка» на конфигурацию.

Если проанализировать  рынок – множество таких решений уже перестали поддерживаться. Везде по разным причинам: где-то компанию покинули разработчики, где-то организации-разработчика уже не существует. Независимо от причины, факт остается фактом – либо переводим конфигурацию «за свой счет», либо теряем заветный функционал.

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

Реструктуризация данных

Реструктуризация данных и сам процесс обновления 1С – очень щепетильные вопросы.

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

Были примеры, когда база обновлялась несколько суток, а в конце система выдавала ошибку о том, что «запись регистра сведений … стала не уникальна». Такая ситуация вполне возможна, на это необходимо обращать внимание и закладывать дополнительное время в копилку рисков.

Процесс обновления (запуск обработчиков обновления при первом запуске программы) тоже не всегда корректно отрабатывает и может неоднократно порадовать «сюрпризами».

Нет единого рецепта, как избежать ошибок при обновлении и реструктуризации, каждый раз может появиться новый нюанс. До непосредственно перехода обязательно прогоните несколько раз «вживую» процедуру обновления и реструктуризацию на серверном оборудовании – это поможет Вам избежать лишних нервов в час «Ч».

Права доступа

Судя по опыту, достаточно часто случаются проблемы с правами доступа. После обновления обязательно проверьте возможность входа пользователя в информационную базу. Как правило, эти проблемы решаются банальной перезаписью прав пользователя (вкладка Группы доступа в элементе справочника «Пользователи»).

Внешние обработки, отчеты, печатные формы

Перевод внешних обработок, отчетов, печатных форм никак не предусмотрен фирмой 1С. Для их «конвертации» необходимо осознано подходить к делу:

• во-первых, требуется перевод форм в режим управляемого приложения;
• во-вторых, по новой методике библиотеки стандартных подсистем необходима подготовка таких файлов.

(Подробности о создании внешних обработок и отчетов в статье ИТС http://its.1c.ru/db/bspdoc#content:22:1:IssOgl2_%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5%D0%BD%D0%BE%D0%B2%D0%BE%D0%B3%D0%BE%D0%BE%D1%82%D1%87%D0%B5%D1%82%D0%B0%D0%B8%D0%BB%D0%B8%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8)

Восстановление нумерации

Сами разработчики заявили, что после обновления программы на 3.0 существует проблема с нумерацией: она «сбивается» и начинает отсчет заново. Для того чтобы вернуть нумерацию, достаточно создать документ с последним кодом, который был в системе.

Например, если последний документ Поступления был с номером 256, мы создаем  документ с этим же номером,  установленным вручную (256), и следующий документ уже будет автоматически иметь номер 257.

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

Правила обмена

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

Для корректной работы нужно загрузить Ваши правила в конфигурацию «Конвертация данных», найти изменившиеся реквизиты и поправить. Если Вы уверены, что знаете, в чем ошибка, можно поправить прямо в xml файле правил, открыв его в блокноте.

Организационные моменты

Последним пунктом среди сложностей стоит отметить организационные вопросы:

Обоснование затрат на обновление клиенту (начальству). Это очень сложный вопрос  для клиента. Совсем недавно был переход с 1.6 на 2.0, а теперь 3.0. Почему клиент должен отдавать деньги за обновление? Утешает только одно:  надеюсь, в ближайшее время не предвидится никаких новшеств и серьезных обновлений.

Оценка трудозатрат по переходу. Время перехода на новую редакцию программы сильно зависит от степени модификации конфигурации. Рекомендуется попытаться воздержаться от преждевременной оценки и попробовать договориться работать «по-факту». Связано это с тем, что процесс реструктуризации может сильно затянуться, а эти проблемы никаким образом нельзя предусмотреть заранее.

Рекомендации по переходу

Подведем некий итог и попробуем дать некоторые  общие рекомендации для более легкого и комфортного перехода:

• Переход планируйте как можно раньше, не тяните до последних дней.
• Желательно, чтобы перенос функционала осуществлялся теми же программистами, которые дорабатывали конфигурацию.
• Попробуйте выделить на реструктуризацию как можно больше времени. Если переходите с понедельника, то начните работу в пятницу вечером.
• Перед финальным обновлением всех доработок обязательно прогоните обновление на тестовой среде. Без «репетиции» Вы рискуете не успеть выполнить обновление в технологическое окно.
• Делайте бекапы всего, что можно, и как можно чаще.
• Переход на 3.0 — это отличный повод для рефакторинга кода и «инвентаризации» доработок. Если Вы видите, что какой-то функционал не используется или перестал быть актуальным, то смело прощайтесь с ним.
• Как можно больше тестируйте перенесенный функционал, создайте тестовую базу и запустите туда пользователей.
• Создайте для пользователей среду, где они познакомятся с программой заранее  — это поможет избежать в дальнейшем простых вопросов при начале работы с 3.0.
• Всегда имейте в запасе «план Б» — если что-то пойдет не так, как планировалось, будьте готовы откатиться на 2.0 для того, чтобы не парализовать работу компании.

Буду рад замечаниям и любой обратной связи о Вашем опыте.