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

[1cwiki]

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

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

В чем особенности перехода?

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

Необходимый релиз

Для перехода на другую конфигурацию нужно немного: релиз конфигурации редакции «2.0», с которого и нужно переходить на новую версию. О том, какой релиз необходим, можно узнать на сайте http://users.v8.1c.ru. Там есть информация о пригодных для обновления актуальных версиях. Например, на сегодня актуальная версия «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». Почему же снова клиент должен отдавать свои средства на обновление? Однако пользователя может утешить то, что в ближайшее время компания «1С» не планирует никаких обновлений и серьезных нововведений.

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

Рекомендации, касающиеся перехода

А сейчас мы сделаем определенные выводы и попытаемся дать советы по более комфортному и простому переходу:

- Не тяните время, планируйте переход как можно раньше;

- Было бы лучше, если бы перенос функционала реализовывался бы теми же специалистами-программистами, которые занимались доработкой конфигурации;

- Желательно на реструктуризацию отвести как можно больше времени. Например, если планируете перейти с понедельника, то лучше будет начать работу в пятницу вечером;

- Перед тем, как будете проводить финальные доработки, надо прогнать обновления на текстовой среде. Без так называемой «репетиции» существует риск не успеть в технологическое окно осуществить обновление;

- Бэкап следует делать всего и эти операции проводить как можно чаще;

- Переход на «3.0» - это хороший повод для «инвентаризации» доработок и рефакторинга кода. Если вы видите, что определенный функционал не используется или потерял свою актуальность, то прощайтесь с ним без колебаний;

- Также можно чаще проводить тестирование над перенесенным функционалом. Сформируйте тестовую базу и запустите в нее пользователей;

- Для пользователей сформируйте такую среду, где они смогут заранее познакомиться с программным продуктом. Это даст возможность в дальнейшем при начале работы с «3.0» избежать простых вопросов;

- В запасе всегда должен быть план «Б». Если что-то не получилось с «3.0», нужно будет вернуться к «2.0», чтобы не остановить работу предприятия.