ООО "Инициатива" - 1С-Франчайзинг
+7(4932) 24-53-03

Доработка типовых конфигураций 1С

Доработка типовых конфигураций 1С

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

Нужно для заказа:

Наличие действующей подписки ИТС. Версию и название конфигурации 1С. Были ли изменения в конфигурации или она типовая. Наличие ТЗ — ускорит работу. Будьте готовы предоставить удаленный доступ (самый простой вариант через программу AnyDesk)

Стоимость

Мин. тарификация

  • 10 часа

Стоимость часа

  • 2 500 руб.

Срок на выполнение

  • от 5-х дней
Изменение исходного кода приложений 1СКогда клиент меняет исходный код решения 1С под свои нужды, ему надо помнить, что поставщик приложения тоже не бездействует и выпускает новые версии, добавляя функциональность и исправляя ошибки. Чтобы при установке новой версии приложения не потерялись изменения, сделанные под потребности клиента, нужно каким-то образом произвести слияние (merge) измененной предыдущей версии приложения и новой версии.Естественно, в «1С» уделяли большое внимание этой задаче и разработали механизм поставки и поддержки, облегчающий ее решение. И несколько деталей о внутреннем устройстве решений «1С».Исходные коды и метаданные прикладного решения «1С» (конфигурации) хранятся в базе данных, в той же самой, в которой лежат данные самого приложения (проводки, данные справочников и документов и т.п.), т.е. программа хранится вместе с данными. База данных с конфигурацией (и данными приложения) в терминологии 1С называется информационной базой (сокращенно – инфобазой).В процессе разработки поставщик конфигурации определяет, какие объекты конфигурации (справочники, документы и т.п.) клиент может менять, а какие – нет.Настройка поставки на стороне поставщика

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

Настройка поддержки на стороне клиента

Когда клиент начинает что-то менять в типовой конфигурации, в инфобазе создаются две конфигурации:

  1. Оригинальная конфигурация поставщика.
  2. Текущая конфигурация, измененная на стороне клиента.

И вот поставщик выпускает новую версию. Она может поставляться в виде полного приложения, а может — в виде пакета обновления с измененными объектами. При переходе на новую версию у нас на стороне клиента имеется 3 конфигурации, на основании которых осуществляется так называемое трехстороннее слияние конфигураций:

  1. Старая конфигурация от поставщика.
  2. Текущая конфигурация клиента (старая конфигурация от поставщика плюс изменения, сделанные в ней клиентом).
  3. Новая конфигурация от поставщика.

Понятно, что в ряде случаев объекты, измененные поставщиком, можно обновлять автоматически:

  • Объекты, не измененные клиентом.
  • Простые изменения объектов на стороне клиента (например, добавление дополнительных реквизитов к объекту).

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

Внешние отчеты и обработки

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

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

Расширения конфигурации

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

  1. Позволял бы легко обновлять кастомизированное решение на новую версию, избегая ручной работы по объединению конфигураций.
  2. Позволял включать кастомизацию при определенных условиях (например, если мы работаем в контексте определенной организации).
  3. Снижал вероятность потери работоспособности кастомизации при переходе на новую версию исходной конфигурации.
  4. Имел возможность отключения кастомизации в случае проблем для сохранения работоспособности приложения.

Такой механизм, помимо применения в облачных решениях, сильно облегчил бы жизнь при переходе на новую версию на внедрениях типовых конфигураций, где необходимы кастомизации.
Мы придумали такой механизм и назвали его расширения. Этот механизм в каком-то смысле совмещает в себе два подхода к кастомизации – идеологию плагинов и механизм подписок.

Расширения – это способ держать изменения конфигурации отдельно от самой конфигурации. Расширение, по сути, само является отдельной конфигурацией, содержащей измененные объекты. Оно так же, как и конфигурация, представляется в виде дерева объектов. Для работы с расширением используются те же приёмы работы, что и с обычной конфигурацией

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

Полезные ссылки

доработка 1с