Особенности перехода с 1С Бухгалтерии 2.0 на 3.0
Какие есть особенности перехода из программы 1С 8.2 на 8.3?
Не так давно фирма «1С» порадовала выходом новой версии прикладного решения 1С: Бухгалтерия предприятия 3.0 и огорчила последующим прекращением поддержки версии 2.0 весной 2014 года. Чуть позже разработчики, по просьбам партнеров, согласились продолжить поддержку версии 2.0 в части регламентированной отчетности до конца 2014 года.
Решение является долгожданным продолжением легендарной серии бухгалтерских программ. Оно обладает принципиально новым интерфейсом (т.н. управляемое приложение), которое открывает перед собой новые возможности: возможна работа в режиме тонкого и веб клиента, размещение приложений в «облаке», формирование отчетов в «фоновом режиме» и другими. Помимо интерфейсных преобразований есть некоторые улучшения по части ведения учета: расширен модуль учета заработной платы, учет налогов стал более удобным и логичным.
Особенности перехода
Переход с 1С Бухгалтерии с версии 2.0 на 3.0 неизбежен для всех организаций, где используется конфигурация. Сам процесс перехода не составляет особого труда и представляет собой простое «обновление» конфигурации на очередной релиз. Но есть и ложка дёгтя. На практике некоторых проектов уже был получен опыт перехода нетиповых конфигураций, которым хотелось бы поделиться. Ниже будут рассмотрены проблемы и особенности, которые встречаются в конфигурациях с уровнем изменений «больше среднего». (если у вас типовая конфигурация вам подойдет инструкция — как обновить 1С Бухгалетерия 3.0)
Нужный релиз
Начнем с исходного: что необходимо для перехода? Необходимо не многое – релиз конфигурации версии 2.0, с которого можно перейти на актуальную версию. Что бы понять какой релиз необходим – нужно найти сайте 1С информацию об актуальной версии, пригодной для обновления. Например, на текущий момент актуальна версия 3.0.27.7, которая может быть обновлена с релиза 2.0.53.6.
Адаптация доработок конфигурации
Если конфигурация нетиповая — первая и самая сложная задача, которая стоит перед «внедренцам» — перенести доработки из функционала «двушки» в «тройку».
Для получения списка изменений – необходимо сравнить конфигурацию базы данных с конфигурацией поставщика (проверьте, что бы конфигурация поставщика была актуальна).
Здесь встречаются следующие особенности:
- Все доработки, сделанные на «обычных» формах нельзя просто так перенести в управляемые формы. Необходимо адаптировать программный код
- Бухгалтерия 3.0 – это, по сути своей, новая программа. Если, например, ранее ваша доработка находилась в функции «РасчитатьПроцентНадбавки» в модуле документа «ПоступленияТоваровУслуг», то теперь такой процедуры может не быть вовсе. Тут встаёт вопрос о необходимости серьезного понимания и анализа каждой доработке
- Если доработки программистов использовали типовые общие модули – с большой вероятностью «ссылки» будут потеряны: общие модули серьезно изменились – как состав их функций, так и их имена (наследие новой БСП 2.х)
- Такая же ситуация с объектами метаданных. Большое количество объектов стали «не нужными» вместо них используется другие объекты, некоторые были переименованы (например – справочник «РегистрацииВИФНС» стал называтся «РегистрацииВНалоговыхОрганах»)
Проблема отраслевых «надстроек»
На текущий момент, на основе конфигурации 1С: Бухгалтерия предприятия существует огромнейшее множество отраслевых решений. Эти решения, зачастую устанавливаются как «надстройка» на конфигурацию.
Если проанализировать рынок – множество таких решений уже перестали поддерживаться. Везде по разным причинам: где то компанию покинули разработчики, где то организации-разработчика уже не существует. Не зависимо от причины,
факт остается фактом – либо переводим конфигурацию «за свой счет», либо теряем заветный функционал.
Этот вопрос очень остро может быть воспринят клиентом, ввиду ограничений бюджета компании на сопровождение и поддержку программных продуктов.
Реструктуризация данных
Реструктуризация данных и сам процесс обновления 1С – очень щепетильные вопросы.
Для реструктуризации может понадобиться много времени. Таблицы с большим количеством записей, даже на хорошем оборудовании, могут реструктуризироваться достаточно долго.
Были примеры, когда база обновлялась несколько суток, а в конце система выдавала ошибку о том, что «запись регистра сведений … стала не уникальна». Такая ситуация вполне возможна, на это необходимо обращать внимание и закладывать дополнительное время в копилку рисков.
Процесс обновления (запуск обработчиков обновления при первом запуске программы) тоже не всегда корректно отрабатывает и может неоднократно порадовать «сюрпризами».
Нет единого рецепта, как избежать ошибок при обновлении и реструктуризации, каждый раз может появиться новый нюанс. До непосредственно перехода обязательно прогоните несколько раз «вживую» процедуру обновления и реструктуризацию на серверном оборудовании – это поможет Вам избежать лишних нервов в час «Ч».
Права доступа
Судя по опыту, достаточно часто случаются проблемы с правами доступа. После обновления обязательно проверьте возможность входа пользователя в информационную базу. Как правило, эти проблемы решаются банальной перезаписью прав пользователя (вкладка Группы доступа в элементе справочника «Пользователи»).
Внешние обработки, отчеты, печатные формы
Перевод внешних обработок, отчетов, печатных форм никак не предусмотрен фирмой 1С. Для их «конвертации» необходимо осознано подходить к делу:
- во-первых, требуется перевод форм в режим управляемого приложения
- во-вторых, по новой методике библиотеки стандартных подсистем необходима подготовка таких файлов
Восстановление нумерации
Сами разработчики заявили, что после обновления программы на 3.0 существует проблема с нумерацией – она «сбивается» и начинает отсчет заново. Для того, что бы вернуть нумерацию достаточно создать документ, с последний кодом, который был в системе.
Например: если последний документ Поступления был с номером 256 — мы создаем документ с этим же номером, установленным вручную(256) и следующий документ уже будет автоматически иметь номер 257.
Для данных целей можно написать простую обработку: создать документ каждого типа с последним существующим номером и пометить его на удаление.
Правила обмена
Если ваша конфигурация обменивалась с другой с помощью правил обмена, то, с очень большой вероятностью, правила перестанут работать. Связано это с тем, что некоторые объекты метаданных стали называться по-другому, некоторые реквизиты были удалены, а некоторые добавлены.
Для корректной работы нужно загрузить ваши правила в конфигурацию «Конвертация данных», найти изменившиеся реквизиты и поправить. Если вы уверены что знаете в чем ошибка, можно поправить прямо в xml файле правил, открыв его в блокноте.
Организационные моменты
Последним пунктом среди сложностей стоит отметить организационные вопросы:
Обоснование затрат на обновление клиенту (начальству). Это очень сложный вопрос для клиента. Совсем недавно был переход с 1.6 на 2.0, а теперь 3.0. Почему клиент должен отдавать деньги за обновление? Утешает только одно: надеемся, в ближайшее время, не предвидится никаких новшеств и серьезных обновлений.
Оценка трудозатрат по переходу. Время перехода на новую редакцию программы сильно зависит от степени модификации конфигурации. Рекомендуется попытаться воздержатся от преждевременной оценки и попробовать договориться работать «по-факту». Связано это с тем, что процесс реструктуризации может сильно затянутся, а эти проблемы никаким образом нельзя предусмотреть заранее.
Рекомендации по переходу
Подведем некий итог и попробуем дать некоторые общие рекомендации для более легкого и комфортного перехода:
- Переход планируйте как можно раньше, не тяните до последних дней
- Желательно, чтобы перенос функционала осуществлялся теми же программистами, которые дорабатывали конфигурацию
- Попробуйте выделить на реструктуризацию как можно больше времени. Если переходите с понедельника, то начните работу в пятницу вечером
- Перед финальным обновлением всех доработок, обязательно прогоните обновление на тестовой среде. Без «репетиции» Вы рискуете не успеть выполнить обновление в технологическое окно
- Делайте бекапы всего что можно и как можно чаще
- Переход на 3.0 это отличный повод для рефакторинга кода и «инвентаризации» доработок. Если Вы видите, что какой то функционал не используется или перестал быть актуальным, то смело прощайтесь с ним
- Как можно больше тестируйте перенесенный функционал, создайте тестовую базу и запустите туда пользователей
- Создайте для пользователей среду, где они познакомятся с программой заранее — это поможет избежать в дальнейшем простых вопросов при начале работы с 3.0
- Всегда имейте в запасе «план Б» — если что то пойдет не так как планировалось, будьте готовы откатиться на 2.0, для того чтобы не парализовать работу компании
По материалам: programmist1s.ru
Не стоит винить ребенка за то, что он боится темноты. Настоящая трагедия – это когда взрослый человек боится света.
