Как обеспечить вывод исторического адреса в печатных формах 1С:Управление торговлей 10.3?

← На главную

В работе со старыми конфигурациями, такими как «Управление торговлей 10.3», пользователи часто сталкиваются с ситуацией, когда при печати старого документа (например, счета на оплату или накладной годовой давности) в печатную форму подставляется текущий юридический адрес контрагента. Это происходит потому, что за прошедшее время клиент сменил адрес, и эти данные были обновлены в его карточке. Проанализируем, почему так происходит и как исправить эту проблему, чтобы документы соответствовали исторической правде.

Выясним причину: почему УТ 10.3 «забывает» старые адреса

Рассмотрим архитектуру хранения данных в типовой версии Управление торговлей 10.3. В отличие от более современной версии Управление торговлей 11, где механизм истории адресов является штатным, в версии 10.3 используется упрощенная схема. Вся контактная информация (адреса, телефоны, email) хранится в регистре сведений КонтактнаяИнформация.

Ключевая особенность этого регистра заключается в том, что он является непериодическим. Это означает, что система не хранит историю изменений. Для каждого контрагента и каждого вида информации (например, «Юридический адрес») существует только одна запись. Когда вы вносите новый адрес, старый безвозвратно стирается из базы данных. Поэтому, когда программный код печатной формы обращается к регистру, он всегда получает единственное доступное — актуальное на данный момент — значение.

Решение 1: Оперативное исправление без программирования

Если нам нужно срочно выдать клиенту документ со старым адресом, а программиста нет под рукой, проанализируем самый простой и быстрый способ решения. Посмотрим на алгоритм действий:

Откроем карточку контрагента в справочнике Контрагенты.
Перейдем на закладку «Адреса и телефоны».
Скопируем текущий (новый) адрес в текстовый файл, чтобы не потерять его.
В поле «Юридический адрес» временно впишем старый адрес, который должен быть в документе.
Запишем изменения в карточке контрагента.
Вернемся в нужный документ (счет, реализацию) и сформируем печатную форму. Теперь в ней отобразится старый адрес.
После печати или сохранения документа в PDF вернем актуальный адрес в карточку контрагента.

Важно: Этот метод подходит только для разовых операций. Если таких документов много, риск ошибиться или забыть вернуть актуальный адрес слишком велик.

Решение 2: Перевод регистра в режим периодичности (для программистов)

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

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

Однако простого изменения структуры регистра недостаточно. Нам необходимо изменить логику извлечения данных в модулях печати. Типовой код в УТ 10.3 обычно использует функции общего модуля УправлениеКонтактнойИнформацией, которые не учитывают дату документа. Нам потребуется изменить запрос, чтобы он выполнял СрезПоследних на дату документа.

Проанализируем пример кода, который необходимо внедрить в функцию получения адреса:


Функция ПолучитьАдресНаДату(ОбъектСсылка, ТипКИ, ВидКИ, ДатаДокумента)
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   КонтактнаяИнформация.Представление
        |ИЗ
        |   РегистрСведений.КонтактнаяИнформация.СрезПоследних(&ДатаДокумента, 
        |       Объект = &Объект И Тип = &Тип И Вид = &Вид) КАК КонтактнаяИнформация";
    
    Запрос.УстановитьПараметр("Объект", ОбъектСсылка);
    Запрос.УстановитьПараметр("Тип", ТипКИ);
    Запрос.УстановитьПараметр("Вид", ВидКИ);
    Запрос.УстановитьПараметр("ДатаДокумента", ДатаДокумента);
    
    Результат = Запрос.Выполнить();
    Если Не Результат.Пустой() Тогда
        Выборка = Результат.Выбрать();
        Выборка.Следующий();
        Возврат Выборка.Представление;
    КонецЕсли;
    Возврат "";
КонецФункции

Решение 3: Фиксация адреса в самом документе

Рассмотрим еще один профессиональный способ решения, который часто применяется при внедрении учетных систем. Чтобы данные в печатной форме никогда не менялись (даже если кто-то случайно изменит историю в регистре), адрес можно «замораживать» непосредственно в документе в момент его проведения.

Для этого выполним следующие действия:

Добавим в документы (например, СчетНаОплатуПокупателю, РеализацияТоваровУслуг) новый реквизит ГрузополучательАдресТекст или ЮридическийАдресКонтрагента с типом Строка.
В процедуру ПередЗаписью или ПриИзменении контрагента добавим код, который автоматически заполняет этот реквизит строковым представлением адреса из карточки контрагента.
Изменим макет и модуль печати документа так, чтобы данные брались не из справочника контрагентов, а непосредственно из реквизита самого документа.

Посмотрим на пример кода для заполнения реквизита документа:


Процедура ЗаполнитьАдресДляПечати()
    Если ЗначениеЗаполнено(Контрагент) Тогда
        // Получаем адрес через типовую функцию
        АдресДляХранения = УправлениеКонтактнойИнформацией.ПолучитьПредставлениеКИПоТипу(Контрагент, Перечисления.ТипыКонтактнойИнформации.Адрес, Справочники.ВидыКонтактнойИнформации.ЮрАдресКонтрагента);
        ЭтотОбъект.АдресДляПечати = АдресДляХранения;
    КонецЕсли;
КонецПроцедуры

Этот метод гарантирует, что даже через 5 лет, вне зависимости от изменений в справочниках или регистрах, печатная форма документа будет идентична оригиналу, выданному клиенту в день сделки.

Подведем итоги

Проанализировав ситуацию, мы выяснили, что проблема некорректного вывода адреса в УТ 10.3 является следствием упрощенной архитектуры хранения контактной информации. Если ваша база «дописана» и в ней уже есть некое подобие истории, значит, разработчик, реализовавший хранение, забыл обновить алгоритмы печати.

Для исправления ситуации мы рекомендуем либо использовать ручную корректировку в исключительных случаях, либо обратиться к программисту для перевода регистра КонтактнаяИнформация в периодический режим с обязательным обновлением запросов в модулях печати всех первичных документов.