Почему в 1С:Управление торговлей смещаются значения контактной информации и появляются «несуществующие» данные?

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

При работе с современными конфигурациями на базе 1С:Предприятие 8.3, такими как «Управление торговлей 11», «ERP» или «Комплексная автоматизация», разработчики и администраторы иногда сталкиваются со странным поведением интерфейса: в табличной части контактной информации значения отображаются некорректно. Например, в поле «Телефон» может внезапно появиться название отдела (например, «Бакалея»), хотя при выполнении обычного запроса к базе данных это значение отсутствует или находится в другом поле. Рассмотрим подробно, почему возникает эффект «смещения» реквизитов и как это исправить.

Механизм хранения контактной информации в современных конфигурациях

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

Ключевая особенность: помимо текстового представления, которое мы видим на форме, существует скрытый реквизит ЗначенияПолей. В нем данные хранятся в формате XML. Именно этот XML-пакет содержит детализацию: код страны, город, улицу, номер телефона без форматирования и, что немаловажно, Комментарий.

Разберем, что происходит при выводе данных на форму:

  1. Программа считывает XML из реквизита ЗначенияПолей.
  2. Специализированный программный модуль, обычно это УправлениеКонтактнойИнформацией, парсит (разбирает) этот XML.
  3. Результаты парсинга распределяются по колонкам визуальной формы.

Если структура XML нарушена или содержит некорректные символы, механизм разбора «сбивается», что и приводит к визуальному смещению данных.

Выясняем причину появления «фантомных» значений

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

Почему же оно «вылезает» не в своем поле? Это происходит в следующих случаях:

Как обнаружить скрытую проблему через отладку и запросы

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


ВЫБРАТЬ
    ПартнерыКонтактнаяИнформация.Ссылка,
    ПартнерыКонтактнаяИнформация.Тип,
    ПартнерыКонтактнаяИнформация.Вид,
    ПартнерыКонтактнаяИнформация.Представление,
    ПартнерыКонтактнаяИнформация.ЗначенияПолей
ИЗ
    Справочник.Партнеры.КонтактнаяИнформация КАК ПартнерыКонтактнаяИнформация
ГДЕ
    ПартнерыКонтактнаяИнформация.Ссылка = &СсылкаНаОбъект

Посмотрим на содержимое колонки ЗначенияПолей. Если мы увидим там XML-структуру, напоминающую следующую, то проблема подтверждается:


<ContactInformation xmlns="http://www.v8.1c.ru/ssl/contactinfo" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Comment>Бакалея</Comment>
    <Presentation>55555</Presentation>
    <Value xsi:type="PhoneNumber" Number="55555">
        <Number>55555</Number>
    </Value>
</ContactInformation>

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

Способы решения проблемы

Рассмотрим несколько вариантов исправления данной ситуации, от простых к более сложным.

Способ 1: Использование стандартного тестирования и исправления

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

Способ 2: Программная перезапись контактной информации

Самый надежный способ исправить «битую» структуру XML — это перезаписать контактную информацию, используя штатные методы БСП. Это заставит систему заново сформировать правильный XML-пакет. Мы можем воспользоваться обработкой, которая для каждого «проблемного» партнера выполнит следующий код:


ОбъектПартнер = ВыбранныйПартнер.ПолучитьОбъект();
Для Каждого СтрокаКИ Из ОбъектПартнер.КонтактнаяИнформация Цикл
    // Читаем текущее представление
    ТекущееПредставление = СтрокаКИ.Представление;
    
    // Очищаем ЗначенияПолей, чтобы система пересобрала их из представления 
    // или перезаписываем через модуль управления КИ
    Если Найти(СтрокаКИ.ЗначенияПолей, "Бакалея") > 0 Тогда
        // Вызываем функцию обновления КИ из программного интерфейса БСП
        УправлениеКонтактнойИнформацией.ОбновитьКонтактнуюИнформациюОбъекта(ОбъектПартнер, СтрокаКИ);
    КонецЕсли;
КонецЦикла;
ОбъектПартнер.Записать();

Важно помнить, что в модуле УправлениеКонтактнойИнформацией существует множество функций для работы с КИ. Использование метода СформироватьXMLПолейКонтактнойИнформации позволит создать корректную структуру, которую парсер формы поймет однозначно.

Способ 3: Очистка спецсимволов

Если выяснилось, что данные попали в базу при программном переносе, проанализируем исходный код загрузки. Необходимо добавить фильтрацию нежелательных символов перед записью в 1С. Разберем пример функции очистки:


Функция ОчиститьСтрокуДляКИ(Знач ВходнаяСтрока)
    // Удаляем символы перевода строки и табуляции, которые могут ломать XML
    Результат = СтрЗаменить(ВходнаяСтрока, Символы.ПС, " ");
    Результат = СтрЗаменить(Результат, Символы.ВК, " ");
    Результат = СтрЗаменить(Результат, Символы.Таб, " ");
    Возврат СокрЛП(Результат);
КонецФункции

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

Смещение значений в табличной части контактной информации в УТ 11 — это не случайный «глюк», а следствие нарушения структуры внутреннего XML-хранилища данных. Проанализировав скрытый реквизит ЗначенияПолей, мы можем обнаружить, что «лишние» данные на самом деле являются частью комментария или других скрытых атрибутов. Для исправления ситуации рекомендуем всегда использовать методы общего модуля УправлениеКонтактнойИнформацией для программной записи данных, так как они гарантируют корректность формирования XML-структуры и избавляют от визуальных артефактов в интерфейсе пользователя.

← На главную