При внедрении 1С:ERP специалисты часто сталкиваются с ситуацией, когда текущие бизнес-процессы компании или требования интеграции со старыми системами (например, УТ 10.3 или самописные конфигурации) требуют иерархической структуры в справочнике ДоговорыКонтрагентов. В типовой конфигурации ERP этот справочник является плоским, что может вызвать затруднения при попытке перенести логику «Папка — это генеральный договор, а элемент — это конкретное приложение или заказ».
В данной статье мы подробно разберем, как можно реализовать подобную структуру, проанализируем технические сложности и рассмотрим альтернативные пути, которые предлагает типовой функционал системы.
Рассмотрим наиболее радикальный, но визуально понятный для пользователей способ — включение стандартной иерархии групп и элементов в свойствах справочника ДоговорыКонтрагентов. Этот метод позволяет создавать привычные папки непосредственно в справочнике.
Проанализируем шаги, которые необходимо предпринять для корректной работы этого механизма, так как простого включения флажка в конфигураторе недостаточно:
Организация, Партнер, Контрагент) обязательны для заполнения и имеют проверку только для элементов. Нам необходимо разрешить заполнение этих данных и для групп, чтобы папки корректно отображались в списках с установленными отборами.Пример реализации логики в модуле объекта для корректного заполнения данных при создании группы:
Процедура ОбработкаЗаполнения(ДанныеЗаполнения, ТекстЗаполнения, СтандартнаяОбработка)
// Если создается группа, ограничиваем стандартные механизмы заполнения
Если ЭтоГруппа Тогда
Если ТипЗнч(ДанныеЗаполнения) = Тип("Структура") Тогда
ЗаполнитьЗначенияСвойств(ЭтотОбъект, ДанныеЗаполнения);
КонецЕсли;
// Отключаем заполнение валют и организаций, специфичных для элементов
Возврат;
КонецЕсли;
// ... стандартный код заполнения для элементов ...
КонецПроцедуры
Процедура ПередЗаписью(Отказ)
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Обеспечиваем наличие владельца и ключевых реквизитов даже у группы
Если ЭтоГруппа Тогда
// Логика проверки заполнения Партнера и Контрагента для иерархии
Если Не ЗначениеЗаполнено(Партнер) И ЗначениеЗаполнено(Родитель) Тогда
Партнер = Родитель.Партнер;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Одной из главных проблем при включении иерархии становится отображение «чужих» папок. Если менеджер открывает список договоров по конкретному партнеру, он ожидает увидеть только его папки. В режиме «Иерархический список» система может выводить пустые папки других контрагентов, если не настроено условное оформление или динамический отбор.
Рассмотрим способ скрытия ненужных групп через Условное оформление динамического списка в форме:
// В процедуре ПриСозданииНаСервере или при изменении отбора по партнеру
Если Параметры.Свойство("Партнер") Тогда
ПартнерДляОтбора = Параметры.Партнер;
Если ЗначениеЗаполнено(ПартнерДляОтбора) Тогда
ЭлементОформления = Список.УсловноеОформление.Элементы.Добавить();
// Условие: если Партнер не равен выбранному
ЭлементОтбора = ЭлементОформления.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
ЭлементОтбора.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Партнер");
ЭлементОтбора.ВидСравнения = ВидСравненияКомпоновкиДанных.НеРавно;
ЭлементОтбора.ПравоеЗначение = ПартнерДляОтбора;
ЭлементОтбора.Использование = Истина;
// Действие: Видимость = Ложь
ЭлементОформления.Оформление.УстановитьЗначениеПараметра("Видимость", Ложь);
КонецЕсли;
КонецЕсли;
Важно: При таком подходе следует помнить о рисках обновления. Справочник ДоговорыКонтрагентов активно используется в логике 1С:ERP, и любые изменения в структуре его метаданных потребуют тщательного контроля при каждом обновлении конфигурации.
Если мы хотим избежать «тяжелых» изменений метаданных, проанализируем более мягкий вариант — добавление реквизита ГоловнойДоговор (ссылка на этот же справочник). Это позволит выстроить иерархию элементов без включения режима групп.
Преимущества данного метода:
ГоловнойДоговор настраивается стандартными средствами без доработки схем компоновки.Выясним, как логика иерархии заложена в саму архитектуру 1С:ERP. Часто потребность в иерархии возникает из желания видеть детализацию взаиморасчетов (например, общая сумма по договору и остатки по конкретным заказам). В ERP для этого не нужно плодить элементы в справочнике договоров.
Рассмотрим шаги настройки расчетов по заказам:
ЗаказКлиента или ЗаказПоставщику становится самостоятельным Объектом расчетов.Этот путь является наиболее правильным с точки зрения методологии 1С, так как он сохраняет чистоту НСИ и позволяет использовать все типовые механизмы контроля лимитов и графиков платежей.
Проанализируем критические моменты, которые могут возникнуть при реализации иерархии через группы:
Обмен данными с БП 3.0: В 1С:Бухгалтерия справочник договоров жестко подчинен владельцу-контрагенту и имеет свою логику иерархии. Если в ERP создать сложную структуру папок, при выгрузке через синхронизацию данных (КД 3.0) папки могут либо игнорироваться, либо создавать дубликаты. Потребуется серьезная доработка правил в составе МенеджераОбменаЧерезУниверсальныйФормат.
Механизм Интеркампани: При использовании схемы передачи товаров между организациями, система автоматически подбирает договоры. Наличие групп в иерархии может сбить алгоритмы автоматического заполнения, если они не ожидают увидеть группу там, где должен быть конкретный объект.
RLS (Ограничение прав доступа): В ERP права часто настраиваются в разрезе групп доступа партнеров. Если папка договора принадлежит одному партнеру, а вложенный договор — другому (в рамках холдинга), механизмы RLS могут скрывать родительскую папку, что сделает работу пользователя в иерархическом списке невозможной.
Подводя итог, разберем рекомендации. Если ваша задача — обеспечить временную синхронизацию со старыми системами, наиболее безопасным будет использование дополнительного реквизита связи или функционала объектов расчетов. К изменению иерархии в метаданных справочника стоит прибегать только в крайнем случае, когда визуальное дерево в стандартном виде «как в старой базе» является критическим требованием бизнеса, а ресурсы на сопровождение кастомной конфигурации позволяют поддерживать эти изменения в будущем.