Информационный выпуск 1С № 16872 от 08.07.2013г. http://www.1c.ru/news/info.jsp?id=16872
Кому будет полезна данная публикация: ..об этом мы узнаем в комментариях =)
Итак, начнем..
Общий план перехода:
0. Когда можно/нужно переходить?
1. Перевод типового функционала.
2. Перевод добавленного функционала.
3. Права доступа.
4. Командный интерфейс.
5. Дополнительные отчеты и обработки.
6. Инструменты разработчика.
7. Настройки программы
0. Когда можно/нужно переходить?
По непонятной мне причине в 1С:Учебном центре №1 преподаватель, который читал курсы по 3.0 заверял обучающихся что переходить нужно с нового года, дискредитировать преподавателя просто не хотелось, но это уже другая история. Однозначного срока нет, есть оптимальный с учетом деятельности предприятия, не ведитесь на стериотипы людей с загустевшим мышлением.
На личном примере перевод рабочей базы на новую редакцию мы осуществили после закрытия 3го квартала, т.к. остатки переносить не нужно, рабочая деятельность ведется в одной базе, до формального закрытия года есть объективно большой срок, за который можно при необходимости выполнить нужные доработки для закрытия года. Сам переход является обновлением, а не переходом на новую программу.
1. Перевод типового функционала.
Этот пункт достаточно прост, переход не требует переноса данных и выполняется как обновление конфигурации. Все что необходимо - это иметь нужные версии конфигурации, исходя из информационного выпуска 1С №16872 от 08.07.2013г. это версии 2.0.49 и 3.0.22
Выполняем обновление текущей конфигурации на версию 2.0.49 применяем обновление, запускаемся в режиме предприятия, подтверждаем легальность, ждем некоторое время пока выполняются необходимые действия, первый шаг пройден.
Выполням обновление с версии 2.0.49 на 3.0.22 При обновлении есть вероятность получить "неразрешимые ссылки" это связанно с тем, что в добавленных объектах могут встречаться ссылки на типовые объекты, которые при обновлении будут удалены. Несколько поэксперементировав было принятно решение при обновлении пометить на обновление (иногда фактически это равносильно удалению) метаданные не связанные с хранением данных.
Важно понимать, что переход на версию 3.0 - это не просто обновление - фактически это переход на "Управляемое приложение", на управляемые формы, на реальное клиент-серверное взаимодействие, это значит что все доработки, которые прежде не были адаптированы к "Управляемому приложению" работать не будут. Имеющиеся роли теряют свою актуальность - в 3.0 они разделены на составные роли, из которых в дальнейшем формируются профили групп доступа. Интерфейсы в управляемом приложении не используются. Всвязи с этим основной задачей при переводе типового функционала является сохранность добавленных вами метаданных участвующих в храненнии информации, например добавленных объектов, реквизитов, табличных частей, движений документов, типов в уже существующих данных, возможно предопределенных элементов (их нельзя удалить, они станут не предопределенными но остануться в базе).
Подсистемы, роли, критерии отбора, общие формы, формы объектов, макеты, журналы, подписки (всю ветку общие, все формы, макеты документов и справочников, все отчеты, все обработки) можно помечать на обновление, при необходимости эти объекты конфигурации можно будет восстановить из копии конфигурации 2.0.
Выполняем объединение. Сохраняем основную конфигурацию. Добавляем пользователю под которым будет выполняться обновление роль "Администратор системы (для перехода на ред. 3.0)". Применяем конфигурацию к информационной базе. Во время применеия изменений к конфигурации могут появится сообщение о дублирующихся именах метаданных, добавте префикс/суффикс к одному из объектов, такие объекты нужно проанализировать в режиме предприятия и выполнив необходимые действия удалить ненужные объекты. Ждем продолжительного обновления в режиме предприятие. На этом шаге могут возникнуть ошибки частного характера, которые можно обойти добавив "попытка/исключение" в нужные места.
Update 23.11.2013:
В настоящее время переход с 2.0 на 3.0 несколько изменился. Для того чтобы перейти на актуальную версию необходимо скачать "Дистрибутив обновления для перехода с редакции 2.0". В описании дистрибутива будут указаны необходимые для возможости обновления версии 2.0, а так же приведена не сложная инструкция.
После обновления конфигурации 2.0 до нужной версии, выполняем обновление конфигурации на редакцию 3.0. Все замечания описанные в п.1 не утратили актуальности.
2. Перевод добавленного функционала.
В зависимости от объема имеющихся изменений конфигурации будет зависеть сложность данного пункта.
По порядку:
2.1. Добавленные документы/справочники - необходимо адаптировать для работы в управляемом приложении: добавить в необходимые подсистемы, разработать управляемые формы, добавить необходимые команды, включить "Использовать стандартные команды", ознакомится с используемыми общими командами и новыми подписками на события.
2.2. Реализация изменений в типовых объектах с учетом работы в управляемом приложении.
2.3. Добавленные отчеты и обработки - есть особенности, об этом ниже.
2.4. Ветка "Общие" как в 2.0.
2.5. При переносе добавленного функционала следует обращать внимание на измененные типовые объекты: процедуры функции общих модулей, переименованные реквизиты/объекты (например ФизЛица/ФизическиеЛица, ДолжностиОрганизаций/Должности), принципиальные отличия в хранении информации (теперь контактная информация хранится непосредственно в табличных частях объектов)
Особенности:
В условиях достаточной срочности перехода и не принципиальности работы в тонком клиенте для пользователей есть возможность сделать переход более плавным, на моем примере повторная реализация порядка 60 отчетов и обработок на управляемых формах заняла бы достаточно долгое время. Есть вариант использования режима запуска "Толстый клиент (управляемое приложение), который настраивается отдельно для отладки и при подключении базы пользователю:
Также необходимо настроить режим открытия форм "В закладках" в режиме 1С:Предприятия (Сервис -> Параметры):
Такой режим запуска позволит использовать старые отчеты/обработки добавленные в конфигурацию (внешние запускаться не будут) в управляемом приложении. Потребуется некоторая переработка отчетов/обработок связанная с п. 5. Так же есть особенности связанные с тем, что вызов из обычных форм серверных процедур/функций возможен только из общих модулей у которых установлен признак "Вызов сервера", поэтому возможно возникнет необходимость создать свой промежуточный модуль с установленным признаком "Вызов сервера" через который вызывать серверные процедуры и функции, например:
СчетФактура = РаботаСОбычнымиФормами.НайтиПодчиненныйСчетФактуруВыданныйНаРеализацию(ОбъектДокРеализации.Ссылка);
Промежуточный модуль:
Функция НайтиПодчиненныйСчетФактуруВыданныйНаРеализацию(ДокументОснование, ИсключаемыйСФ = Неопределено, ПометкаУдаления = Ложь, СтруктураОтбора = Неопределено) Экспорт
Возврат УчетНДСПереопределяемый.НайтиПодчиненныйСчетФактуруВыданныйНаРеализацию(ДокументОснование, ИсключаемыйСФ, ПометкаУдаления, СтруктураОтбора);
КонецФункции
Также при работе с обычными формами в упрвляемом приложении следует учитывать возможные подписки на события для типовых объектов, обработчики которых могут быть размещены в общих модулях без признака "Вызов сервера", например при создании в обработке объекта документа РеализацияТоваровУслуг появится ошибка "При подписке АвтономнаяРаботаЗарегистрироватьИзменениеДокумента на событие ПередЗаписью произошла ошибка. Обработчик события не найден." это связанно с тем что ваша обработка/отчет выполняется в контексте толстого клиента и не видит данную подписку в серверном модуле. В таком случае вам необходимо ставить признак "Вызов сервера" у типового модуля, подписок может быть очень много, также можно нарваться на передачу мутабельного значения, поэтому можно попробовать воспользоваться промежуточным обращением через модуль, с установленным признаком "Вызов сервера", например:
СчетФактураОбъект = РаботаСОбычнымиФормами.ВыполнитьНаСервере(Истина, "Документы.СчетФактураВыданный.СоздатьДокумент()");
РаботаСОбычнымиФормами.ВыполнитьНаСервере(Ложь, "Параметр1.УстановитьНовыйНомер(Параметр2)", СчетФактураОбъект , РеализацияТоваровУслугОбъект.Организация.Префикс);
Промежуточный модуль:
Функция ВыполнитьНаСервере(ВернутьРезультат, Команда, Параметр1 = Неопределено, Параметр2 = Неопределено, Параметр3 = Неопределено, Параметр4 = Неопределено) Экспорт
Если ВернутьРезультат Тогда
Возврат Вычислить(Команда);
Иначе
Выполнить(Команда);
Возврат Неопределено;
КонецЕсли;
КонецФункции
Таже было выявлено, что при использовании методов объектов из толстого клиента напрямую, не обрабатываются стандартные процедуры из модуля объекта, например при использовании метода документа Заполнить() не вызывается процедура ОбработкаЗаполнения(), т.е. промежуточный модуль все-таки придется использовать если вы работаете с методами объекта.
Для отображения обычных обработок/отчетов в интерфейсе, нужно включить использование стандартных команд для объекта либо создать соответствующие команды в которых вызвать открытие формы обработки/отчета.
&НаКлиенте
Процедура ОбработкаКоманды(ПараметрКоманды, ПараметрыВыполненияКоманды)
//Вставить содержимое обработчика.
ПараметрыФормы = Новый Структура("",);
ОткрытьФорму("Обработка.ГрупповоеФормирование.Форма", ПараметрыФормы, ПараметрыВыполненияКоманды.Источник, ПараметрыВыполненияКоманды.Уникальность, ПараметрыВыполненияКоманды.Окно);
КонецПроцедуры
Использование обычных форм для управляемого приложения может быть применено и для справочников/документов, но учитывая использование в них стандартных механизмов которые в любом случае необходимо будет адаптировать, занятие это бесполезное. В любом случае данная особенность возможности запуска обычных форм не должна использоваться априори, а только при необходимости с дальнейшим переходом к управляемым формам.
3. Права доступа.
Система организации прав доступа используется из "Библиотеки стандартных подсистем" номер подсистемы 47, название "Управление доступом". Используется "Упрощенный интерфейс настройки прав доступа".
С точки зрения конфигурирования (как и должно было быть) организация доступа осталась на прежнем уровне.. т.е. пользователь информационной базы имеет доступ (программный и интерфейсный, +rls) согласно тем ролям которые ему добавлены по принципу если где-то разрешено, значит можно.
В режиме предприятие все достаточно сильно изменилось, попробую описать логику организации доступа:
Справочник "Пользователи" связан по ИД со списком пользователей информационной базы (раньше вроде было по коду).
В программе есть функциональная опция "ИспользоватьГруппыПользователей" которая включает возможность использовать соответственно группы пользователей, но эти группы пользователей обеспечивают только функционал визуального разделения.
В программе есть функциональная опция "ОграничиватьДоступНаУровнеЗаписей" которая включает возможность использования разграничения доступа по организациям.
Новое: Справочник "Профили групп доступа" - осуществляется настройка некоего набора доступных ролей информационной базы. Есть предопределенные элементы профелей групп доступа, предопределенные элементы не меняются (не менялись) по составу ролей, если нужно что-то поменять создаем собственный профиль.
Справочник "Группы доступа" - обеспечивает организацию доступности набора ролей для пользователя, есть элементы с видом "Персональные группы доступа" которые создаются для каждого пользователя всегда и могут быть включены или выключены, есть элементы с видом "Произвольные участники" в которые добавляется список нужных пользователей. При использовании упрощенного интерфейса настройки прав доступа (по умолчанию, но можно отключить) при установке прав доступа пользователя (отметка необходимых профилей пользователя) пользователю создаются соответствующие группы доступа(для RLS), и проставляются соответствующие роли для связанного пользователя информационной базы.
В общем виде мы имеем некую зависимость: Пользователь -> Профиль доступа -> Группы доступа/Роли.
Сложности: при переходе только пользователь от которого выполнялся переход зарегистрировался в справочнике пользователей, остальные в справочнике пользователей не появились, хотя остались в списке пользователей информационной базы, для того чтобы избежать повторного создания пользователей (и генерации новых паролей =)) предлагаю воспользоваться прикрепленной обработкой (лучше сначала на копии) возможно в более новых релизах для перехода на 3.0 данная проблема не возникнет, но мало ли.
Во время создания собственных ролей наткнулся на очень неприятный нюанс, когда роли "зависают" и изменения не применяются при перезапусках отладки. Проблема заключалась в том, что в 1С используются механизмы кэширования и сохранения настроек, которые просто так не чистятся, необходимо использовать обработку из "инструментов разработчика" (есть в шаблоне конфигурации SSL/Библиотека стандратных подсистем), файл кому нужно прикрепил, обработка типовая.
4. Командный интерфейс.
В конфигурации есть команды: стандартные, которые нужно не забывать включать для объектов ,устанавливая признак "использовать стандартные команды", к ним относятся команды открытия форм, форм списка, выбора, добавления изменения и т.д. И есть прочие команды: общие команды, команды печати, добавленные пользователем команды.
Для того чтобы команда отображалась в интерфейсе она должна быть включена в подсистему, для подсистемы должен быть включен признак "включать в командный интерфейс" и для команды в командном интерфейсе подсистемы (масло маслянное)) должна быть установлена видимость.
Далее накладываются доступность команды по ролям - если у пользователя есть нужная роль на объект/команду - команда доступна в интерфейсе.
Далее накладываются возможные функциональные опции команды.
Далее накладываются возможные настройки отображения команды для пользователя.
Т.е. все достаточно просто =)) если что-то не отображается, а должно, скорее всего забыли включить "использовать стандартные команды" или работает какая-либо функциональная опция, которая как правило связана с константой. В 3.0 столкнулся с достаточно большим объемом скрытых настроек.
5. Дополнительные отчеты/обработки.
Необходимо переделать для работы в управляемом приложении (примеры на инфостарте).
6. Инструменты разрабочтика.
Есть небольшая особенность, о которой многие забывают, многое из того что вы используете сейчас в обычном приложении (консоли запросов, обработки по поиску дублей и управлению объектами) уже работают под 8.2, не обязательно искать нужную обработку под управляемое приложение если ее использование не имеет постоянного (несколько раз в день) характера. При необходимости вы можете запуститься в толстом клиенте обычном приложении (или запустить соответствующую отладку) и воспользоваться имеющейся обработкой, данную тему я пытался раскрыть в публикации //infostart.ru/public/188602/
7. Настройки программы
По данному разделу хотелось бы озвучить следующие вещи:
В целом при переходе на новую редакцию очень порадовало, что настройку клиент-банка, загрузку данных из ЗУП не нужно было производить повторно (у нас были доработки по правилам обмена, поэтому были свои нюансы).
Повторно прошлись по настройкам параметра учета и настройкам учетной политики, загрузить адресный классификато.
В редакции 3.0 очень много плюшечек из библиотеки стандартных подсистем, скрытых функциональными опциями, к которым не было доступа из интерфейса, например уже реализована подсистема "Присоединенные файлы" и есть возможность "Хранить файлы в томах на диске". Мы использовали подсистемы БСП уже достаточно давно и при переходе я был приятно удивлен, что теперь сопровождать подсистему нет необходимости =). Скорее всего вопрос возможных настроек программы - это только вопрос времени, а возможно просто не хотят перенагружать интерфейс. В моем случае я позаимствовал из БСП общие формы настроек и добавил их в новую подсистему.
