← На главную

При оформлении документов контрагентам часто требуется точное соответствие юридического адреса учредительным документам и выписке из ЕГРЮЛ. Нередко адрес содержит обозначение «комната» (например, «ком. 12»), в то время как при заполнении контактной информации по классификатору программа предлагает выбрать только «кв.» или «оф.». Разберем причины такого поведения системы и рассмотрим практические способы решения этой задачи как пользовательскими средствами, так и с помощью доработки конфигурации.

Выясним причину: почему классификатор не дает выбрать «комнату»?

Проанализируем архитектуру хранения контактной информации в типовой конфигурации «1С:Комплексная автоматизация 1.1». Источником проблемы является не сам адресный классификатор (КЛАДР), а структура метаданных конфигурации:

1. Ограничения КЛАДР: адресный классификатор исторически содержит структурированные данные только до уровня улицы или номера дома/владения. Внутренние помещения (офисы, квартиры, комнаты, склады) классификатором не регламентируются.
2. Ограничения метаданных конфигурации: в КА 1.1 контактная информация хранится в специализированных регистрах сведений, а поля адреса жестко привязаны к предопределенным структурам. Тип помещения определяется системным перечислением ТипыКвартир, в котором разработчиками изначально предусмотрены только два значения — «Квартира» и «Офис». Именно поэтому в выпадающем списке выбора физически нет значения «комната».

Вариант 1. Редактирование текстового представления адреса вручную

Рассмотрим самый простой и безопасный пользовательский способ, не требующий внесения изменений в программный код и базу данных. Большинство типовых печатных форм (счет-фактура, товарная накладная ТОРГ-12, УПД, акт об оказании услуг) при выводе адреса обращаются не к составным частям структуры, а выводят готовое строковое поле Представление.

Разберем по шагам алгоритм действий:

1. Откроем карточку контрагента и перейдем на вкладку ввода юридического или фактического адреса.
2. Заполним адрес через стандартный классификатор, чтобы программа корректно определила регион, город, улицу и почтовый индекс. В поле типа помещения временно выберем любое значение (например, «оф.») и укажем номер комнаты.
3. Нажмем кнопку записи адреса, чтобы сформировалась итоговая строка.
4. В поле полного строкового представления адреса вручную заменим символы «оф.» на необходимое сокращение «ком.».
5. Сохраним карточку контрагента.

Обратите внимание: если в будущем открыть диалоговое окно ввода адреса по классификатору и нажать «ОК», строковое представление будет автоматически перезаписано типовым механизмом, и сокращение «ком.» снова заменится на первоначальное значение. Предупредите пользователей о необходимости сохранять ручную правку.

Вариант 2. Перенос обозначения комнаты в поле строения или корпуса

Если контрагентов с такими адресами много и ручная правка итоговой строки неудобна, применим обходной прием структурированного ввода:

1. В диалоговом окне ввода адреса оставляем поле типа помещения («Тип квартиры») пустым, а номер квартиры/офиса не заполняем.
2. В поле «Корпус» или «Строение» вносим данные вместе с нужным префиксом, например: комн. 15 или лит. А, ком. 3. Либо вписываем это уточнение непосредственно в поле «Дом» (например, д. 12, комната 4).
3. При таком заполнении алгоритм формирования полного адреса соединит поля без добавления нежелательных сокращений «кв.» или «оф.».

Вариант 3. Использование произвольного (неструктурированного) адреса

Посмотрим на еще одну возможность типового интерфейса. Контактная информация контрагента допускает хранение адреса в виде произвольного текста без жесткой привязки к классификатору. Если данный контрагент не участвует в специфических обменах данными, где требуется строго разобранный по полям адрес, можно ввести юридический адрес в виде сплошной строки точно так, как он указан в выписке из ЕГРЮЛ или свидетельстве о регистрации. Для формирования первичных учетных документов этого полностью достаточно.

Вариант 4. Доработка через Конфигуратор (для программистов)

Разберем вариант кардинального решения задачи на уровне метаданных. Для того чтобы сокращение «ком.» появилось непосредственно в выпадающем списке выбора диалогового окна, потребуется внести изменения в конфигурацию:

1. В дереве метаданных находим объект Перечисление.ТипыКвартир.
2. Добавляем новое значение, например, Комната, и задаем ему синоним «ком.».
3. Вносим изменения в модуль управления контактной информацией (общий модуль формирования адресных сведений) и в форму ввода адреса, чтобы новое значение перечисления корректно обрабатывалось при разборе и генерации итоговой строки представления.

Важные риски доработки конфигуратора:

1. Снятие конфигурации с полной поддержки: потребуется включить возможность изменения метаданных, что усложнит процедуру последующих обновлений.
2. Сбои при синхронизации и обмене данными: если база КА 1.1 обменивается сведениями с «1С:Бухгалтерией», «1С:ЗУП» или работает в распределенной информационной базе (РИБ), появление нового значения системного перечисления приведет к критическим ошибкам сериализации XDTO и срыву обмена, пока идентичные изменения не будут внесены во все узлы и правила конвертации.
3. Форматы ЭДО и отчетности: старые схемы выгрузки электронных документов в ФНС могут содержать жесткие валидаторы формата, не поддерживающие нестандартные типы помещений.

Итоги и рекомендации

Мы проанализировали специфику работы с адресами в «1С:Комплексная автоматизация 1.1». Классификатор КЛАДР не регулирует типы комнат, а изменение метаданных в конфигураторе несет существенные риски для обменов данными. Оптимальным решением для повседневного учета остается корректировка текстового представления адреса вручную либо ввод уточнения комнаты в поля «Корпус/Строение», что гарантирует корректный вывод данных в печатные формы без изменения типовой конфигурации.