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