Часто при автоматизации бизнес-процессов возникает необходимость привязать к конкретному адресу доставки (например, партнера или контрагента) определенный склад отгрузки. Стандартные подсистемы (БСП) предоставляют мощный механизм контактной информации (КИ), однако добавление в него новых реквизитов имеет свои архитектурные особенности. Давайте разберем по шагам, почему простое добавление поля на форму не работает, и проанализируем правильные способы решения этой задачи.
Для начала выясним причину такого поведения системы. Многие разработчики пытаются просто добавить реквизит на форму ввода адреса или в табличную часть КонтактнаяИнформация, но обнаруживают, что после перезапуска формы поле очищается.
Дело в том, что в современных версиях Библиотеки стандартных подсистем (БСП) контактная информация не хранится в виде классических отдельных колонок (индекс, город, улица и т.д.) в базе данных. Для каждого адреса система формирует специальную структурированную строку в формате XML (XDTO-пакет) или JSON. Эта строка записывается в скрытое системное поле (обычно ЗначенияПолей или Значение) табличной части справочника-владельца.
Когда вы нажимаете кнопку сохранения, типовой программный код собирает только строго определенные стандартом поля. Ваш нетиповой реквизит Склад алгоритмом игнорируется. Более того, попытки "вклиниться" в типовую XML-строку и добавить туда свой тег могут привести к ошибкам обмена данными, так как схемы XDTO жестко валидируют структуру.
Рассмотрим подробнее три рабочих варианта решения этой задачи от простых к более сложным.
Это наиболее архитектурно правильное и чистое решение. Оно не требует снятия типовой конфигурации с поддержки и не ломает стандарты обмена контактной информацией. Мы просто свяжем адрес и склад в отдельной таблице.
СкладыАдресовДоставки.ОбъектВладелец (тип: СправочникСсылка.Партнеры или Контрагенты) и ИдентификаторСтрокиКИ (или ВидКонтактнойИнформации, если у партнера только один адрес такого вида).Склад (тип: СправочникСсылка.Склады).ПриСозданииНаСервере) читайте склад из регистра по владельцу и идентификатору и заполняйте добавленный на форму реквизит.ПослеЗаписиНаСервере или при закрытии формы ввода адреса) записывайте выбранное значение обратно в ваш регистр сведений.Этот метод гарантирует, что обновления БСП не затрут вашу логику, а типовой функционал останется нетронутым.
Если вы не хотите плодить новые объекты метаданных (регистры), проанализируем ситуацию с использованием существующего поля Комментарий, которое есть в табличной части КИ.
Пользователю все так же выводится красивое поле со списком складов. Но программно под капотом мы будем "упаковывать" этот склад вместе с текстом комментария.
Склад на форму программно через расширение.Комментарий табличной части.Комментарий. Наш код парсит JSON, извлекает GUID, находит по нему ссылку на склад и подставляет в визуальное поле выбора склада. Оставшийся текст выводится в обычное поле комментария.Пример концептуальной структуры в поле комментарий:
{
"ТекстКомментария": "Доставлять только после 14:00",
"СкладУИД": "123e4567-e89b-12d3-a456-426614174000"
}
Этот вариант обсуждался на форуме, но его стоит применять только если конфигурация уже сильно переписана и снята с поддержки.
Посмотрим на алгоритм:
КонтактнаяИнформация справочника (например, Клиенты) новый реквизит Склад.Минусы подхода: Очень много изменений в типовых модулях. Выгружаться в другие базы стандартными планами обмена это поле не будет (потребуется доработка правил конвертации). При каждом обновлении 1С придется вручную проверять и переносить этот код.
Мы настоятельно рекомендуем использовать Вариант 1 (Регистр сведений). Он наиболее прозрачный, легко интегрируется через механизм расширений и не ломает типовые XDTO-пакеты библиотеки стандартных подсистем. Работа с адресами в БСП требует аккуратности, и вынесение дополнительных свойств в отдельные сущности — залог стабильной работы вашей базы.