Что такое кастомизированная 1с

Обновлено: 04.07.2024

Рассмотрим основные возможности адаптации на примере внедрения «1С ERP: Управление предприятием 2»:

Методы кастомизации
Механизм «Расширение»
Преимущества расширений
Недостатки расширений

Методы кастомизации

Компания 1С предоставляет несколько возможностей для кастомизации:

использование внешних обработок / отчетов / печатных форм;
расширение конфигурации.

Механизм «Расширения конфигурации»

Рассмотрим механизм «Расширения конфигурации», его основные возможности и ограничения.

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

Кастомизированный программный продукт, с которым работает пользователь, является сложением двух конфигураций: исходной конфигурации и конфигурации расширения.

У механизма расширения есть 3 назначения:

исправление;
адаптация;
дополнение.

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

Преимущества расширений

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

Возможность обновления конфигурации из пользовательского режима сохраняется;
Возможность использования нескольких расширений для одной исходной конфигурации;
Не требуется высокая квалификация специалиста, обслуживающего программу;
Исключена возможность потери доработанных объектов и блоков при обновлении;
Исключена возможность длительной потери работоспособности доработанного программного продукта при переходе на новую версию исходной конфигурации;
Возможность подключения и отключения расширений из пользовательского режима;
Применение исправлений и модификация расширений конфигурации не влияет на текущую работу пользователей.

Недостатки расширений

Недостатки расширений связаны с увеличением сложности и времени процесса разработки:

Увеличение сложности проведения глобальных (объемных) обновлений, требуется контроль разработанного функционала в расширениях конфигурации, автоматический контроль отсутствует;
Ограничения, связанные с возможностями разработки:

a. При использовании конструктора запросов обрабатываются только метаданные, имеющиеся в расширении;

b. При добавлении новых объектов метаданных обязательно указание роли «Полные права» (исправлено в платформе вер. 8.3.14);

c. Исключена возможность изменения и дополнения типов (составов) объектов метаданных;

d. Отсутствует возможность создания объектов метаданных: «Константы», «Регламентные задания»;

e. Исключен вызов «Перед» и «После» при доработке функций основной конфигурации;

f. Отсутствует возможность добавления регистров, подчиненных регистратору;

g. Отсутствует возможность добавления параметров сеанса, значений перечисления (исправлено в платформе вер. 8.3.14);

h. Отсутствует возможность добавления одного объекта метаданных в несколько расширений;

j. После подключения расширения конфигурации, расширяющего данные, не поддерживается использование фоновой реструктуризации.

По многочисленным просьбам в версии 8.3.22 в язык запросов и в язык выражений СКД добавится функция УникальныйИдентификатор(Ссылка). Параметр Ссылка - выражение, результатом которого является ссылка (кроме ссылок на таблицы внешних источников данных). Функция возвращает уникальный идентификатор переданной ссылки или NULL, если передано значение NULL.

18.11.2021 Обновлён план задач на версию 8.3.22 платформы 1С:Предприятие

Обновлены статусы задач в плане на версию 8.3.22 платформы 1С:Предприятие.

19.10.2021 Вебинар, посвященный выходу платформы 8.3.20

Вебинар, посвященный выходу платформы 8.3.20, пройдет 26 октября в 11:00.

На вебинаре будет рассказано об основных новинках этой версии платформы.

В конце вебинара можно будет задать вопросы разработчикам.

Для участия в вебинаре необходимо:

06.10.2021 Расширение поддержки работы с НТТР-запросами

29.09.2021 Анонс новых возможностей языка 1С:Исполнитель

До конца 2021 года планируется к выпуску новая версия 1С:Исполнитель.

26.09.2021 Новая технология разработки приложений

В ближайшее время нами планируется выпуск продуктов «1С:Кабинет сотрудника» и «1С:Шина» с возможностями кастомизации. Для кастомизации будет использоваться новая технология «Элемент».

20.09.2021 Опрос "Использование возможностей интерфейса "Такси""

16.09.2021 Помощь пользователю при проблемах при запуске системы и другие доработки

В версии 8.3.21 мы сделали ряд доработок, призванных сделать взаимодействие системы с пользователем более удобным для пользователя.

09.09.2021 Работа внешних компонентов в отдельном процессе

С целью повышения стабильности работы системы в версии 8.3.21 появится возможность запускать внешние компоненты в отдельном процессе (как при работе на сервере, так и на клиенте). Таким образом, если во внешней компоненте произойдет необработанное исключение – оно не вызовет аварийного завершения вызывающего процесса, в котором работает пользователь, и пользователь сможет продолжить работу.

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Акиньшин Александр Сергеевич, Акатова Наталья Анатольевна

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

CUSTOMIZATION TECHNIQUE FOR TYPICAL APPLIED IT SOLUTIONS BASED ON THE TECHNOLOGICAL PLATFORM “1C: ENTERPRISE 8”

The concept and signs of the customization project are defined. The methodology for customization of standard design solutions based on the technological platform “ 1C : Enterprise 8” has been developed. The technique allows you to determine the functional gaps between the implemented information system and the identified requirements, prioritize them using the combined method. The technique also permits you to determine the feasibility of implementing a functional gap, identify implementation’s risks of the required functionality, and assess the criticality of this functionality for users. Using the methodology , a suitable customization mechanism is determined for the implementation of the functional gap, which will further reduce the cost of updating the configuration.

Текст научной работы на тему «Методика кастомизации типовых прикладных ИТ-решений на базе технологической платформы «1С:Предприятие 8»»

МЕТОДИКА КАСТОМИЗАЦИИ ТИПОВЫХ ПРИКЛАДНЫХ ИТ-РЕШЕНИЙ НА БАЗЕ ТЕХНОЛОГИЧЕСКОЙ ПЛАТФОРМЫ

Акиньшин Александр Сергеевич, студент 2 курса магистратуры, Национальный исследовательский технологический университет «МИСиС», Москва, Россия,

Научный руководитель: Акатова Наталья Анатольевна, кандидат экономических наук, доцент, Национальный исследовательский технологический университет «МИСиС», Москва, Россия..

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

Ключевые слова: методика, кастомизация, 1С, типовая конфигурация, ИТ-проект, адаптация ИС/

Keywords: methodology, customization, 1C, typical configuration, IT project, IS adaptation/

В современной практике ведения ИТ-проектов понятие «Кастомизация» до сих пор было не определено, а употреблялось в профессиональной области ведения проектов автоматизации деятельности различных предприятий в качестве «профессионального сленга» обозначения услуги внедрения коробочного продукта [1]. В то же время уже накоплен достаточный опыт ведения проектов адаптации [2] и доработки типовых прикладных ИТ-решений, требующий систематизации и определения базовых понятий [3]. Под типовым прикладным ИТ-решением в статье будем понимать ИТ-решение автоматизации типовых задач учета и управления предприятия. Для формирования новой методики кастомизации типовых прикладных ИТ-решений на базе технологической платформы «1С:Предприятие 8» необходимо дать определение самого понятия кастомизации и сформулировать признаки, по которым проект может быть квалифицирован как проект кастомизации.

Для выделения основных признаков и компонент понятия в исследовании были проанализированы практики фирм 1С, SAP, Oracle, Microsoft [4], материалы 25 статей и докладов профильных конференций.

Кастомизация - это процесс адаптации и доработки типового прикладного ИТ-решения под специфические требования и нестандартные бизнес-процессы предприятия-заказчика с помощью набора специальных методов, механизмов и языков программирования. Здесь под адаптацией понимается - специфическая настройка параметров типового прикладного ИТ-решения, а под доработкой - новая разработка нестандартных компонентов в составе типового прикладного ИТ-решения.

По степени адаптации и доработки все ИТ-проекты можно разделить на 3 группы:

- внедрение типового прикладного ИТ-решения;

- кастомизация и внедрение типового прикладного ИТ-решения ;

- разработка и внедрение прикладного ИТ-решения «с нуля».

Исходя из представленной классификации для ИТ-проектов внедрения

типового прикладного ИТ-решения на базе платформы 1С:Предприятие, можно сформулировать признаки, позволяющие идентифицировать проект кастомизации:

1) Кастомизированное решение базируется на типовом прикладном ИТ-решении и не предусматривает разработку «с нуля».

2) Кастомизация не предполагает только пользовательскую настройку типового прикладного ИТ-решения, ввод начальных данных и нормативно -справочной информации.

3) Кастомизация предполагает следующие виды изменений:

- Доработка печатных форм и обработок - изменение внешнего вида и содержания печатных форм для нужд предприятия [5];

- Создание новых и модификация существующих отчетов. Отчет -конечный продукт любой аналитической информационной системы, в том числе и 1С Предприятие;

- Создание новых объектов конфигурации: справочников, документов, обработок, регистров и др.;

- Разграничение доступа - детализированное разграничение прав доступа для пользователей;

- Настройка автоматизации - автоматизация и упрощение однотипных функций;

- Добавление в конфигурацию нового функционала - расширение функционала программы;

- Интеграция - настройка обменов между 1С и другими сервисами, такими как банк, сайт, документооборот и т.д.

Методика кастомизации типовых прикладных ИТ-решений на базе технологической платформы «1С:Предприятие 8» включает в себя 5 этапов (рис.1).

1 этап Выявление функциональных разрывов

Рисунок 1. Этапы методики кастомизации типовых прикладных ИТ-решений на базе технологической платформы «1С:Предприятие

Этап 1. Выявление функциональных разрывов

Первый этап методики кастомизации включает в себя 6 подэтапов (рис.2).

Рисунок 2. Описания 1 этапа методики Так, на пятом подэтапе происходит формирование самих функциональных разрывов, при этом последним подэтапом является приоритезация этих функциональных разрывов с помощью комбинированного метода на основе Scorecard и Walking Skeleton. Вначале, по методу Walking Skeleton, указываются связанные между собой требования, которые должны быть реализованы в одном релизе. Далее по методу Scorecard для каждого из требований, по утвержденным заинтересованными сторонами критериям и весам, устанавливаются баллы по согласованной шкале.

Определяется порядка 5-9 критериев, например: полученная прибыль после реализации функции в системе; критичность для реализации бизнес-процесса; важность функционала для пользователей\клиентов; необходимость

решения для последующих доработок продукта; уровень технического риска при реализации задачи; срочность реализации функционала.

Таким образом для каждого требования считается суммарное количество баллов по критериям и весам, исходя из которых выставляется их приоритет. Однако, если есть связанные требования, то для них считается комбинированная оценка как средний балл для связанных требований. Это позволяет определить единый комбинированный приоритет для тесно связанных требований. Комбинированный метод реализован в ПП Microsoft Excel.

По итогам реализации первого этапа методики кастомизации формируется документ ТЗ на разработку и внедрение Системы автоматизации, которая наполняется соответствующими разделами выходных документов на каждом из подэтапов, в том числе модели AS-IS и TO-BE, область автоматизации, базовая типовая конфигурация и ИТ-архитектура; требования к системе, которые включают описание решений по автоматизации, реализующимися с помощью типового функционала и перечень доработок системы, т.е. перечень функциональных разрывов.

Этап 2. Подбор механизмов кастомизации

Второй этап методики кастомизации включает в себя 7 подэтапов (рис.3).

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

Например, для того чтобы заполнить раздел «Целесообразность кастомизации» консультант-аналитик совместно с системным архитектором должен проанализировать все риски, с которыми может столкнуться как команда внедрения, так и пользователи системы при реализации функциональных разрывов. Оценка рисков производится по количественному методу с использованием вероятности (W) и влияния (P).

Рисунок 3. Описания 2 этапа методики Составляется реестр рисков при реализации функционального разрыва, который может содержать, например, следующие виды рисковых событий, представленных в таблице 1.

Таблица 1. Матрица степени угрозы риска реализации функционального разрыва (У)

№ Вид риска Вероятность (Р) Влияние Степень угрозы (У)

А. Функциональный разрыв 1

1 Негативное влияние объекта

кастомизации на другие объекты в 0,4 0,5 0,2

2 Снятие с поддержки типовой конфигурации и как следствие, проблемы с ее обновлением до актуальных версий поставщика в дальнейшем 0,2 0,5 0,1

3 Негативное влияние на

производительности информационной 0,6 0,2 0,12

Итого (среднее) 0,21

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

Таблица 2. Шкала степеней угроз

Принять Принять Оценить Оценить Оценить

риск риск степень степень степень

важности важности важности

Рекомендуемы недостающего недостающего недостающего

е дальнейшие функционала функционала функционала у

действия у у функционально

функциональ функциональ го заказчика

Соответственно, если степень угрозы средняя и выше, то необходимо обсудить с функциональным заказчиком насколько важна и необходима требуемая ему доработка. Для этого используем матрицу критичности недостающего функционала у функционального заказчика с использованием влияния функционала и частоты обращения к функционалу (V), где R = 0,2 - функционал используется «по традиции» и необходим пользователям, которые привыкли так работать; R = 0,5 - функционал позволяет сократить трудозатраты одного или нескольких пользователей; R = 0.75 - без данного функционала не могут работать смежные подразделения или вся организация. V = 0,2/0,4/0,6/0,8/1 если частота обращения к функционалу 1/год, 1/квартал, 1/месяц, 1/неделю, ежедневно соответственно.

Умножив параметры R и V, получаем степень критичности функционала для пользователя которая соизмерима со степенью угрозы реализации этого функционала. Однако для степени критичности используется специальный коэффициент который определяет возможность реализации данного функционала другими, возможно менее рациональными, но и менее рискованными методами или средствами. Если Кя=0,5, то возможно реализовать необходимый функционал другими методами или средствами, и если К=1, то необходимый функционал нельзя или нецелесообразно решать альтернативными методами или средствами. Коэффициент умножается на

степень критичности и получаем итоговую степень критичности недостающего функционала.

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

1) Y > В, то подрядчику необходимо провести организационную встречу с представителями заказчика, на которой показать возможные риски при реализации необходимого функционала и убедить, что данный функционал нецелесообразно реализовывать с помощью инструмента 1С.

2) Y < В, принять риски и получить подпись функционального заказчика о необходимости реализации недостающего функционала, предварительно ознакомив его с возможными рисками.

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

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

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

Таблица 3. Механизмы кастомизации по видам изменений

———^^^ Механизм 1 2 3 4 5 6 7 8 9 10

Создание внешних отчетов и обработок ✓ ✓ ✓ ✓

———^^^ Механизм ———^^^ кастомизации Вид изменения —— 1 2 3 4 5 6 7 8 9 10

Создание новых и модификация существующих отчетов. ✓ ✓ ✓ ✓ ✓

Добавление дополнительных сведений или полей к существующим объектам ✓ ✓ ✓

Создание новых объектов конфигураций: справочников, документов, обработок, регистров и др ✓ ✓ ✓

Детализированное разграничение прав доступа ✓

Настройка автоматизации - автоматизация и упрощение однотипных функций ✓

Расширение функционала программы ✓ ✓

где 1 - Пользовательские настройки форм и отчетов, автоподстановки; 2 -Библиотека стандартных подсистем (Механизмы БСП); 3 - Механизм бизнес-событий; 4 - Настройка прав в разрезе аналитик; 5 - Механизм настройки шаблонов печатных форм; 6 - Внешние отчеты и печатные формы; 7 -Механизмы компоновки данных; 8 - Механизмы гибкой интеграции с другими системами 1С: 9 - Механизм расширений; 10 - Программирование на внутреннем языке.

Этап 3. Кастомизация

Третий этап методики кастомизации включает в себя 5 подэтапов (рис.4). На данном этапе происходит реализация функционального разрыва и обновление пользовательской документации.

Рисунок 4. Описания 3 этапа методики Этап 4. Передача системы в опытную эксплуатацию

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Четвертый этап методики кастомизации включает в себя 5 подэтапов (рис.5). Этап характеризуется установкой и настройкой типовой конфигурации и ее перевод в Опытную эксплуатацию.

Рисунок 5. Описания 4 этапа методики

Этап 5. Передача системы в промышленную эксплуатацию

Пятый этап методики кастомизации включает в себя 3 подэтапа, при этом первые 2 подэтапа выполняются опционально, в зависимости от конкретного проекта (рис.6).

Рисунок 6. Описания 5 этапа методики

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

1. Лухин П.А., Романов Б.Л., Слободецкий Д.Я., Тарханов И.А. Быстрая кастомизация программных продуктов на основе коробочного решения / Труды института системного анализа российской академии наук, 2009

2. Соммердфельд А.В. Управление проектом адаптации ERP систем // Сборник научных статей 2-й Всероссийской научной конференции перспективных разработок молодых ученых Московский политехнический университет, 2018

3. Тоноян С. А., Балдин А. В. Методика модернизации стандартных модулей типовой конфигурации на базе технологической платформы «1С:Предприятие 8» с минимальными доработками // Наука и образование: научное издание МГТУ им. Н.Э. Баумана. 2012. № 8. С. 17.

4. А. В. Суворов. Сравнение систем автоматизации управления производством // Социально-экономическое управление: теория и практика. 2010. № 2 (18). С. 211-228.

1. Lukhin P. A., Romanov B. L., Slobodetsky D. Ya., Tarkhanov I. A. Fast customization of software products based on a boxed solution / Proceedings of the Institute of system analysis of the Russian Academy of Sciences, 2009

2. Sommerfeld A. V. management of the project of adaptation of ERP systems // Collection of scientific articles of the 2nd all-Russian scientific conference of promising developments of young scientists Moscow Polytechnic University, 2018

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

Алексей Тютякин, разработчик 1С в компании Neti, рассказывает о расширениях конфигурации и предупреждает о подводных камнях, с которыми может столкнуться каждый программист.

Краткая справка

Технология с довольно скудным функционалом появилась в 2015 году, в платформе 8.3.6.

Возможности расширений в типовых конфигурациях зависят от режима совместимости, который обычно ограничен версией БСП. На февраль 2021 года в основных линейках типовых конфигураций (ЕРП, БП, ЗУП) используется БСП версии 3.1.3 и режим совместимости 8.3.14.

В базовых версиях расширения не поддерживаются.

Как это выглядит при разработке

Как это выглядит при разработке. Есть основная конфигурация и ее расширение (отдельная мини-конфигурация). Объекты бывают собственными, созданными в самой конфигурации или в расширении, и заимствованными, захваченными из основной конфигурации в расширение. Для заимствованных объектов можно переопределять ряд свойств.

Свойства объектов бывают контролируемые и модифицируемые. Контролируемые свойства менять нельзя — они должны совпадать у основной конфигурации и расширения, иначе расширение не запустится. Модифицируемые свойства можно изменять в расширении.

Возможности технологии

В версии платформы 8.3.14, поддерживаемой современными типовыми решениями, широкий спектр возможностей для изменения. В частности, можно:

менять большое количество свойств заимствованных объектов;
создавать собственные справочники, документы и РС;
создавать и переопределять подсистемы и роли, шаблоны доступа;
переопределять практически все модули и формы;
версионировать расширения в хранилище.

В последних версиях платформы появилось множество интересных возможностей. Отметим самые существенные:

в версии 8.3.13 — поддержка создания своих РН, РБ, РР и связанных объектов, функционал планов обмена;
в 8.3.14 — собственные параметры сеанса, что дает полноценное создание своих РЛС;
в 8.3.15 — появилась возможность заимствовать процедуры и функции с контролем изменения кода в основной конфигурации и в расширении — аннотация &ИзменениеИКонтроль;
в 8.3.16 — создание собственных констант, функциональных опций и критериев отбора, изменение состава заимствованных критериев отбора и функциональных опций;
в 8.3.17 — создание своих подписок на события и заимствование существующих;
в 8.3.18 — возможность расширения состава типов заимствованных объектов (с некоторыми исключениями, например, для определяемого типа).

Более подробно с описанием механизма расширений можно узнать в следующих материалах:

Кейс: переход на ЗУП 3.1 КОРП в федеральной торгово-производственной компании

Основной источник кейсов для этой статьи — проект перехода на ЗУП 3.1 КОРП с ЗУП 2.5 в крупной торгово-производственной компании. Особенности проекта:

холдинговая структура, состоящая из десятка юрлиц;
пять тысяч сотрудников;
существенная текучка кадров и большой объем документооборота;
управленческий учет, аналогичный ЗУП 2.5.

Важное требование заказчика: доработки конфигурации необходимо выполнить только с помощью расширений. Удалось на 99%, 1% — ограничения технологии, о которых поговорим отдельно.

Проект выполнялся на версии платформы 8.3.13, 8.3.15, поэтому для некоторых кейсов сейчас доступны альтернативные решения.

Собственные структуры данных

Одна из первых задач любого внедрения — адаптация структуры хранимых данных к реалиям конкретного проекта, то есть расширение структуры данных.

С версии 8.3.11 платформа умеет через расширения создавать справочники, документы, регистры сведений. С 8.3.13 — РН, РБ, РР, полноценные планы обмена, ПВХ, ПС, ПР.

Эти возможности широко применялись на проекте для расширения структуры данных. Расширялся реквизитный состав заимствованных справочников и документов, добавлялись собственные документы, регистры сведений, регистры накопления. Более того, на смежном проекте внедрения решения 1С:ERP в той же компании проектная команда решила не использовать дополнительные реквизиты вообще. В итоге для описания всей специфики номенклатуры в едином расширении было создано более 100 новых реквизитов, десяток перечислений и справочников-классификаторов. Результат по производительности не ставит каких-либо значимых вопросов, все работает так же быстро, как и типовая ERP.

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

Однако стоит учитывать ряд особенностей:

1. Тип ЛюбаяСсылка не содержит ссылок на собственные типы расширения. Механизмы, использующие этот тип, с данными расширения работать не будут.

2. Если в заимствованный справочник/документ добавлен новый реквизит, необходимо захватить в расширение роль, дающую права на этот справочник/документ, иначе реквизит останется без прав и не будет показан на форме.

Хранение новых реквизитов

Рассмотрим способ реализации хранения данных в расширении. Под новые справочники и документы создаются новые таблицы. Они помечаются суффиксом Х и порядковым номером. Например, Reference789X1.

Когда в заимствованный объект расширения добавляется новый реквизит, табличная часть или реквизит табличной части, в базе данных копируется весь набор таблиц объекта с теми же суффиксами в названиях. Например, для таблицы справочника Reference34 будет создана Reference34X1, для новой табличной части может быть создана таблица Reference34_VN34437X1.

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

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

Есть особенность в работе глобального метода ПолучитьСтруктуруХраненияБазыДанных(): в именах таблиц не показываются суффиксы, поэтому определить этим методом наличие или отсутствие расширенной структуры невозможно.

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

Во второй части статьи о расширениях поговорим о РН, изменении режима совместимости, доработке модулей и форм, отчетах и печатных формах.

Читайте также: