Как получить связанный документ EDI на основании данных из регистра сведений

← На главную

В практике интеграции 1С с внешними системами электронного документооборота (EDI) часто возникает ситуация, когда документы не имеют прямой ссылки друг на друга (не заполнен реквизит ДокументОснование). Вместо этого они связываются через уникальный идентификатор, который хранится в дополнительных свойствах или специальных регистрах. Типичный пример — связь Заказа покупателя и Заказа EDI (например, от сети Metro), где связующим звеном выступает «Номер заказа покупателя в системе ритейлера».

В данной статье мы разберем, как программно найти ссылку на документ ЗаказEDI, основываясь на значении, записанном в регистре сведений ЗначенияСвойствОбъектов для конкретного ЗаказаПокупателя. Мы проанализируем структуру запроса, оптимизируем его и рассмотрим нюансы работы с типами данных в 1С.

Анализ исходной задачи

Рассмотрим ситуацию подробнее: у нас есть текущий документ ЗаказПокупателя. В его дополнительных свойствах (которые хранятся в типовом регистре ЗначенияСвойствОбъектов) записан строковый номер. Этот же номер содержится в реквизите НомерВСистемеПокупателя документа ЗаказEDI. Наша цель — получить ссылку на ЗаказEDI, зная только ссылку на ЗаказПокупателя.

Основные объекты метаданных:

Документ.ЗаказПокупателя — текущий объект, от которого мы отталкиваемся.
Документ.ЗаказEDI — искомый объект.
РегистрСведений.ЗначенияСвойствОбъектов — мост между документами.
ПланВидовХарактеристик.СвойстваОбъектов — определяет тип свойства (например, "НомерЗаказаМетро").

Реализация поиска через запрос

Самый эффективный способ решить эту задачу — использовать механизм запросов. Мы должны соединить таблицу регистра сведений с таблицей документов EDI по условию равенства значений. Выясним причину, по которой простые запросы могут не работать: часто это связано с несоответствием типов (например, строка в регистре и строка в реквизите документа могут иметь разную длину или лишние пробелы).

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


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

// Установка параметров
Запрос.УстановитьПараметр("ТекущийЗаказ", Ссылка);
// Находим нужное свойство по наименованию или через предопределенный элемент
СвойствоНомерМетро = ПланыВидовХарактеристик.СвойстваОбъектов.НайтиПоНаименованию("НомерЗаказаМетро");
Запрос.УстановитьПараметр("Свойство", СвойствоНомерМетро);

Выборка = Запрос.Выполнить().Выбрать();

Если Выборка.Следующий() Тогда
    СсылкаНаEDI = Выборка.СсылкаНаЗаказEDI;
    // Теперь у нас есть ссылка на документ-основание
КонецЕсли;

Разбор ключевых моментов запроса

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

Внутреннее соединение (INNER JOIN): Мы соединяем регистр и документ по значению. Это позволяет базе данных сразу отсечь записи, которые не имеют совпадений, что значительно ускоряет выполнение.
Параметр "Объект": В регистре ЗначенияСвойствОбъектов поле Объект имеет составной тип. Передавая в параметр конкретную ссылку на ЗаказПокупателя, мы точно позиционируемся на свойствах нужного документа.
Свойство: Очень важно фильтровать по конкретному виду свойства (&Свойство), так как у документа может быть много доп. реквизитов (дата доставки, код склада и т.д.), и значения в них могут случайно совпасть с номером заказа.

Важные рекомендации по оптимизации

Рассмотрим подробнее технические нюансы, которые могут повлиять на стабильность работы кода в высоконагруженных системах:

1. Обработка строковых значений
Если номер в ЗаказеEDI хранится с лидирующими нулями, а в регистр он записывается без них (или наоборот), запрос не вернет результат. В 1С функции работы со строками в запросах ограничены. Поэтому рекомендуется перед записью данных в регистр и в документ приводить их к единому формату, используя функцию СокрЛП().

2. Проверка типов в регистре
Поскольку поле Объект в регистре ЗначенияСвойствОбъектов составное, для ускорения работы SQL-сервера в сложных запросах можно добавить условие типа:

ГДЕ ЗначенияСвойствОбъектов.Объект ССЫЛКА Документ.ЗаказПокупателя

3. Индексация
В типовых конфигурациях измерение Объект и Свойство в регистре ЗначенияСвойствОбъектов индексированы. Однако поле Значение обычно не имеет индекса (так как оно имеет тип Характеристика.СвойстваОбъектов). Если документов EDI в базе десятки тысяч, поиск по значению может замедлиться. В этом случае стоит рассмотреть создание собственного регистра сведений "Связи документов", где измерениями будут ссылки на оба документа.

Альтернативный подход: Поиск через EDI-идентификаторы

Посмотрим на ситуацию с точки зрения профессиональной разработки модулей обмена. Многие EDI-провайдеры (такие как Контур, Edisoft или Docrobot) используют свои служебные регистры. Если вы работаете с готовым модулем, поищите в конфигурации регистры с названиями вроде СоответствияОбъектовЭДО или СвязиДокументов.

Связь через GUID сообщения (Unique ID) гораздо надежнее, чем связь по текстовому номеру заказа. Номер заказа теоретически может повториться в разных годах, а идентификатор сообщения в системе EDI — никогда.

Итоги

Мы выяснили, что для получения документа на основании регистра необходимо четко сопоставить идентификаторы в обеих таблицах. Использование механизма свойств объектов в 1С — гибкий, но требующий аккуратности метод. Основные правила успеха: использование ВНУТРЕННЕГО СОЕДИНЕНИЯ, точная передача параметров Свойство и Объект, а также контроль чистоты строковых данных. Выполнение этих условий гарантирует корректную работу алгоритма даже при больших объемах данных в системе.