При интеграции «1С:Бухгалтерии 3.0» со ФГИС «Меркурий» (ВетИС) пользователи часто сталкиваются с архитектурным ограничением платформы при работе с сетевыми клиентами. Типичная ситуация: у вас есть один контрагент (например, индивидуальный предприниматель или юридическое лицо), который владеет несколькими торговыми точками (магазинами, складами). При загрузке данных из ВетИС система получает список всех зарегистрированных площадок (предприятий) этого контрагента. Однако при попытке сопоставить эти предприятия с одной карточкой контрагента в 1С возникает ошибка «Торговый объект сопоставлен более чем одному предприятию».
В этой статье мы подробно разберем, почему возникает эта ошибка, проанализируем внутреннюю логику работы интеграции ВетИС в 1С и рассмотрим два основных способа решения проблемы: штатный методологический путь и вариант для программистов с доработкой системы через расширение конфигурации.
Выясним причину такого поведения системы. В интеграционном механизме ВетИС сопоставление данных происходит на двух независимых уровнях:
Контрагенты (или Организации для собственных юридических лиц). Здесь связь обычно строится «один к одному» по ИНН.Склады (для собственных нужд) либо со справочником Контрагенты (для точек доставки покупателей). В интерфейсе и коде этот реквизит называется «Торговый объект».Данные сопоставления записываются в специализированный регистр сведений. Поле ТорговыйОбъект выступает в качестве ключевого измерения. Система жестко контролирует уникальность: одному торговому объекту в 1С может соответствовать ровно одно предприятие ВетИС. Это необходимо для того, чтобы при оформлении исходящих документов (например, «Исходящая транспортная операция ВЕТИС») программа могла однозначно определить по выбранному в реализации контрагенту-получателю, на какую именно площадку в Меркурии отправляется подконтрольный товар.
Если сопоставить одного и того же контрагента сразу с несколькими предприятиями ВетИС, алгоритм автоматического подбора площадки сломается, так как у программы не будет критерия для выбора конкретного GUID получателя среди десятка одинаковых контрагентов.
Рассмотрим по шагам, как решить эту задачу без изменения программного кода конфигурации «1С:Бухгалтерия 3.0». Для этого мы задействуем стандартный механизм обособленных подразделений контрагентов.
Несмотря на то, что у индивидуальных предпринимателей (ИП) законодательно не бывает филиалов или обособленных подразделений с уникальными КПП, в рамках управленческого и логистического учета в 1С этот механизм отлично подходит для разделения точек доставки одного контрагента.
Выполним следующие настройки в информационной базе:
Контрагенты и создадим одну основную («головную») карточку нашего клиента. Например: «ИП Иванов И.И. (Головной)». В этой карточке заполним все основные реквизиты: ИНН, банковский счет, юридический адрес и договор. Именно по этой карточке будут проходить все проводки и взаиморасчеты по счету 62.Контрагенты. Например: «ИП Иванов И.И. (Магазин №1)», «ИП Иванов И.И. (Магазин №2)» и так далее.Контрагенты, которые логически связаны с одним юридическим лицом. Перейдем в рабочее место сопоставления ВетИС и свяжем каждое загруженное предприятие Меркурия с соответствующим обособленным подразделением. Ошибка уникальности больше не появится.Проанализируем преимущества данного подхода для бухгалтера:
Разберем частый вопрос пользователей: почему нельзя просто использовать встроенный механизм хранения адресов доставки внутри контактной информации одного контрагента? Дело в том, что поле Торговый объект в регистре сопоставления ВЕТИС может принимать только ссылочные типы данных (такие как СправочникСсылка.Склады или СправочникСсылка.Контрагенты). Программа физически не умеет связывать GUID площадки Меркурия с текстовой строкой адреса из табличной части контактной информации. Именно поэтому разделение на карточки-подразделения является единственным стандартным выходом.
Если по каким-то причинам бухгалтерия категорически отказывается плодить карточки обособленных подразделений в справочнике Контрагенты, проблему можно решить путем программной доработки конфигурации. Посмотрим на логику решения этой задачи в коде.
Наша цель — позволить выбирать одного и того же контрагента в качестве торгового объекта для нескольких предприятий ВетИС и скорректировать алгоритм определения получателя при формировании исходящих транспортных операций ВетИС.
Для реализации этого нам потребуется создать расширение конфигурации и переопределить поведение контроля уникальности при записи сопоставления, а также доработать процедуру заполнения документов ВетИС. Рассмотрим пример реализации механизма через переопределение функции получения предприятия-получателя:
&Вместо("ОпределитьПредприятиеПолучателя")
Функция Мой_ОпределитьПредприятиеПолучателя(ДокументРеализации, КонтрагентПолучатель)
// Если у контрагента сопоставлено несколько предприятий ВетИС,
// система должна предоставить пользователю выбор или определить его по адресу доставки.
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| СоответствиеПредприятий.ПредприятиеВЕТИС КАК ПредприятиеВЕТИС,
| СоответствиеПредприятий.ПредприятиеВЕТИС.АдресРучнойВвод КАК Адрес
|ИЗ
| РегистрСведений.СоответствиеОбъектовВЕТИС КАК СоответствиеПредприятий
|ГДЕ
| СоответствиеПредприятий.ТорговыйОбъект = &КонтрагентПолучатель";
Запрос.УстановитьПараметр("КонтрагентПолучатель", КонтрагентПолучатель);
ТаблицаПлощадок = Запрос.Выполнить().Выгрузить();
Если ТаблицаПлощадок.Количество() = 1 Тогда
Возврат ТаблицаПлощадок[0].ПредприятиеВЕТИС;
ИначеЕсли ТаблицаПлощадок.Количество() > 1 Тогда
// Реализуем сопоставление по адресу из документа реализации
АдресДоставкиРеализации = ДокументРеализации.АдресДоставки;
Для Каждого СтрокаПлощадки Из ТаблицаПлощадок Цикл
Если Найти(ВРег(СтрокаПлощадки.Адрес), ВРег(АдресДоставкиРеализации)) > 0 Тогда
Возврат СтрокаПлощадки.ПредприятиеВЕТИС;
КонецЕсли;
КонецЦикла;
// Если не удалось определить по адресу, возвращаем первое попавшееся или вызываем форму выбора
Возврат ТаблицаПлощадок[0].ПредприятиеВЕТИС;
КонецЕсли;
Возврат Справочники.ПредприятияВЕТИС.ПустаяСсылка();
КонецФункции
При использовании программного метода важно помнить о потенциальных рисках:
Проанализируем, почему в других типовых решениях от «1С» (например, в «Управлении торговлей 11» или «ERP») эта проблема не стоит так остро. В торговых системах архитектура ведения партнеров существенно отличается от «1С:Бухгалтерии»:
Партнером (который и выступает в роли «Торгового объекта» доставки), в то время как ХС ВетИС связывается с юридическим Контрагентом.Контрагенты, что и привело к описываемому ограничению.Таким образом, мы детально разобрали обе методики преодоления ограничения сопоставления торговых объектов в «1С:Бухгалтерии 3.0». Для большинства организаций предпочтительным и безопасным остается штатный путь создания обособленных подразделений. Он гарантирует стабильность обмена с ВетИС при обновлениях программы и сохраняет прозрачность ведения бухгалтерского учета.