Как избавиться от лишних пробелов при обмене данными с фиксированной длиной строки?

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

Почему возникают проблемы с фиксированной длиной строки?

Строка фиксированной длины в 1С — это тип данных, который жестко ограничивает объем хранимой информации. Если для реквизита КорСчет в конфигураторе установлена длина, например, 34 символа, а само значение счета занимает всего 20, платформа автоматически дополняет оставшееся пространство пробелами. Это поведение заложено на уровне архитектуры 1С.

Когда используется механизм XDTO-сериализации, правила обмена ожидают строгого соответствия типов данных XSD-схеме. Если на стороне отправителя контроль XDTO отключен для обхода ошибки длины поля, система начинает передавать «заполненную пробелами» строку, которая воспринимается получателем как корректный, но «загрязненный» набор данных.

Как решить проблему на стороне получателя?

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

1. Использование стандартных функций очистки: Для того чтобы избавиться от пробелов справа, слева или с обеих сторон строки, в 1С предусмотрены встроенные функции СокрЛ(), СокрП() и СокрЛП().
2. Внедрение логики в правила обмена: Если обмен настроен через КД 2.0 или КД 3.0, наиболее правильным местом для обработки данных будет обработчик события ПослеЗагрузки или ПередЗагрузкой в правилах конвертации объекта (ПКО) или правилах конвертации свойства (ПКС).

Пример программной обработки данных

Представим, что мы получаем объект справочника БанковскиеСчета. В коде обработчика загрузки нам необходимо применить функцию СокрП() (сокращение пробелов справа), чтобы очистить корсчет перед записью в базу:

// Пример обработчика ПослеЗагрузки в правилах конвертации
Если ЗначениеЗаполнено(Объект.КорСчет) Тогда
    Объект.КорСчет = СокрП(Объект.КорСчет);
КонецЕсли;

// В случае если данные приходят через XDTO-пакет, 
// можно принудительно очистить строку перед присвоением:
ОчищенныйСчет = СокрП(ВходящееЗначение);
Объект.КорСчет = ОчищенныйСчет;

Рекомендации по архитектуре

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

• Не модифицируйте типовые реквизиты: Если банковский счет требует расширения длины, лучше создать новый ДополнительныйРеквизит, чем менять свойства типового поля, на которое завязаны механизмы обмена и валидации.
• Контролируйте типы данных: Если реквизит может содержать данные разной длины, используйте тип Строка с переменной длиной (неограниченная строка или строка с максимально допустимым запасом без жесткой фиксации), если это позволяет логика конфигурации.
• Валидация на входе: При получении данных от внешних систем всегда добавляйте проверку входных параметров. Даже если обмен работает «автоматически», очистка данных от лишних пробелов спасет вас от ошибок при построении отчетов или формировании платежных поручений.

Проанализировав ситуацию, можно сделать вывод: борьба с пробелами — это классическая задача интеграции. Раз мы не можем изменить поведение платформы 1С для фиксированных строк, мы должны научиться управлять данными программно с помощью СокрП() на этапе их приема.