При переходе на современные конфигурации семейства 1С (Управление торговлей 11, Комплексная автоматизация 2, ERP) пользователи и разработчики часто сталкиваются с новой для них двухконтурной архитектурой учета субъектов бизнес-отношений. В отличие от старой доброй «1С:Управление производственным предприятием 1.3» или «Управление торговлей 10.3», где существовал только один справочник Контрагенты, здесь мы видим разделение на Партнеров (управленческий контур) и Контрагентов (регламентированный/финансовый контур).
В процессе работы с обособленными подразделениями крупных клиентов у бизнеса часто возникает соблазн упростить себе жизнь и «зеркалировать» подчиненность из одного справочника в другой. Например, автоматически подчинять управленческого партнера-филиала головному партнеру при указании головного контрагента в юридической карточке. В этой статье мы подробно разберем, почему эта идея таит в себе скрытые методологические ловушки, детально проанализируем архитектуру обоих справочников и рассмотрим лучшие практики настройки холдинговых структур в 1С. Для масштабных проектов автоматизации доступен раздел с решениями по переносу данных в 1С:Управление холдингом.
Для того чтобы принять взвешенное решение о кастомизации системы, сначала детально разберем, зачем разработчики 1С пошли на разделение единого ранее справочника на две независимые сущности. Для сохранения истории учета при смене программы применяется перенос данных из 1С:УПП 1.3 в 1С:ERP, включающий выгрузку документов и остатков.
Рассмотрим простую жизненную ситуацию. Крупный федеральный ритейлер имеет одно юридическое лицо (Контрагент), но сотни магазинов по всей стране (Партнеры). Менеджеру по продажам для анализа эффективности работы и планирования логистики необходимо видеть продажи в разрезе каждого магазина. А бухгалтерии для выставления счетов-фактур и контроля задолженности нужен только один контрагент-плательщик. Именно эту задачу решает разделение контуров. Если бухгалтерский контур требуется выделить в отдельную информационную систему, используется перенос данных из 1С:ERP 2 в 1С:Бухгалтерию предприятия 3.0.
Вернемся к идее автоматического подчинения партнеров вслед за контрагентами с помощью подписок на события. Предположим, при создании обособленного подразделения (нового контрагента) система автоматически создает подчиненного партнера. На первый взгляд, это кажется удобным: структура дублируется, в базе поддерживается порядок. Однако здесь мы сталкиваемся с критической проблемой ведения взаиморасчетов в 1С.
Проанализируем, как система делает записи в регистры накопления (например, в регистр РасчетыСКлиентами). Ключ взаиморасчетов в современных конфигурациях 1С формируется по трем обязательным аналитикам:
[Партнер] + [Контрагент] + [Договор / Объект расчетов]
Если для каждого обособленного подразделения мы создаем связку «свой Партнер — свой Контрагент» (пусть даже они иерархически подчинены головным элементам), для системы это будут абсолютно разные ключи расчетов. Посмотрим на примере, к чему это приведет в повседневной практике:
Взаимозачет задолженности или использовать сложный ручной зачет оплат в каждой реализации. Это колоссальная и бессмысленная нагрузка на персонал.Вместо того чтобы ломать типовую логику программы доработками, рассмотрим три классические схемы настройки холдингов и филиалов, заложенные разработчиками 1С.
Эта схема идеально подходит для работы с сетями уровня «Ашан», «Магнит» или любыми региональными сетями.
Контрагенты создается всего один контрагент — юридическое лицо, которое производит оплату по договору. Новые контрагенты под каждый магазин не создаются.Используется, когда филиалы клиента имеют статус обособленных подразделений, свои КПП и должны фигурировать в печатных формах УПД в качестве грузополучателей.
Самый простой случай, когда у клиента просто много адресов доставки, но юридическое лицо и КПП везде одинаковые.
В этой ситуации не нужно плодить сущности ни в партнерах, ни в контрагентах. Достаточно создать одного партнера и одного контрагента. В карточке партнера заполняется табличная часть «Адреса доставки». При оформлении заказа менеджер просто выбирает нужный адрес из выпадающего списка.
Если руководство компании все же настаивает на автоматическом создании и подчинении партнеров при создании обособленных подразделений контрагентов, рассмотрим технические риски такой реализации.
Во-первых, это создаст конфликт при возможном переходе на независимый учет партнеров и контрагентов в будущем. Жесткая привязка «один к одному» через код лишит систему гибкости, когда одному крупному партнеру понадобится сопоставить несколько независимых контрагентов.
Во-вторых, это усложнит интеграцию с EDI-провайдерами и торговыми площадками. При работе с EDI обмен заказами жестко завязан на GLN-коды (Global Location Number). Автоматически сгенерированная иерархия партнеров может запутать EDI-модуль, и он не сможет корректно сопоставить пришедший XML-заказ со справочниками в базе 1С.
Если решение о доработке принято окончательно, программисту следует реализовать подписку на событие ПередЗаписью или ПриЗаписи для справочника Контрагенты. Рассмотрим пример упрощенного кода для понимания механики:
Процедура ПередЗаписьюКонтрагентаПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
// Проверяем, что это обособленное подразделение и у него заполнен головной контрагент
Если Источник.ОбособленноеПодразделение И ЗначениеЗаполнено(Источник.ГоловнойКонтрагент) Тогда
// Находим партнера головного контрагента
ГоловнойПартнер = Источник.ГоловнойКонтрагент.Партнер;
Если ЗначениеЗаполнено(ГоловнойПартнер) Тогда
// Получаем объект партнера текущего контрагента
ТекущийПартнерОбъект = Источник.Партнер.ПолучитьОбъект();
Если ТекущийПартнерОбъект <> Неопределено Тогда
// Устанавливаем родителя для партнера
ТекущийПартнерОбъект.Родитель = ГоловнойПартнер;
Попытка
ТекущийПартнерОбъект.Записать();
Исключение
ЗаписьЖурналаРегистрации("СинхронизацияПартнеров", УровеньЖурналаРегистрации.Ошибка,,,
ОписаниеОшибки());
КонецПопытки;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Важное предупреждение: Приведенный код является лишь демонстрацией логики. На практике необходимо обрабатывать множество нюансов: контролировать транзакционность записи, избегать бесконечной рекурсии вызовов при перезаписи связанных объектов, обрабатывать ситуации, когда партнер еще не создан (при первом создании контрагента через Помощник), а также учитывать права доступа пользователя, выполняющего операцию.
Идея автоматически связывать и подчинять партнеров вслед за контрагентами не является абсурдной только в рамках очень простых бизнес-моделей, где включен режим «Использовать партнеров как контрагентов» (связь один к одному). Во всех остальных случаях попытка жестко синхронизировать эти два справочника идет вразрез с методологией разработчиков 1С.
Мы рекомендуем подробно объяснить руководству и финансовому отделу риски «зависания» авансов и усложнения взаиморасчетов. В большинстве случаев бизнес-требования идеально закрываются стандартными средствами: использованием схемы «Один партнер — много контрагентов» или простым ведением адресов доставки в карточке партнера. Использование типового функционала без программирования сбережет бюджет компании на внедрение и гарантирует легкое обновление конфигурации в будущем. Если же из-за специфики учета у вас уже возникли расхождения по аналитике взаиморасчетов, решить эту проблему поможет обработка для автоматического группового создания взаимозачетов задолженности.