При переносе данных между информационными базами на платформах 1С 8.3 и 1С 7.7 разработчики часто сталкиваются с проблемой сопоставления контрагентов. В современных конфигурациях 1С 8.3 реквизиты ИНН и КПП разделены и хранятся в разных полях. В то же время в устаревших базах 1С 7.7 (например, в «Бухгалтерском учете 7.7» или «Торговле и Складе 7.7») под ИНН часто выделен один строковый реквизит, в который пользователи записывают данные в формате "ИНН/КПП" (например, 5994512/18100101).
Если передавать из источника только чистый ИНН, стандартный механизм поиска «Конвертации данных» не сможет сопоставить контрагентов, что приведет к созданию дублей. Рассмотрим подробнее, как решить эту проблему программными методами на разных этапах конвертации.
Самый простой и логичный подход — подготовить данные к формату приемника еще на этапе выгрузки. Для этого мы будем использовать обработчик событий правила конвертации свойств (ПКС).
Перейдем в правила конвертации свойств для реквизита ИНН и в обработчике «Перед выгрузкой» напишем код, который будет объединять ИНН и КПП через косую черту. При этом важно учитывать особенности контрагентов разных типов:
Чтобы избежать выгрузки некорректных строк вида 123456789012/ (с "висящим" слешем на конце), обязательно добавим проверку заполнения реквизита КПП:
Если ПустаяСтрока(Объект.КПП) Тогда
Значение = СокрЛП(Объект.ИНН);
Иначе
Значение = СокрЛП(Объект.ИНН) + "/" + СокрЛП(Объект.КПП);
КонецЕсли;
Этот способ отлично работает, если в базе-приемнике 1С 7.7 все данные заведены единообразно и строго через косую черту /.
На практике пользователи базы 1С 7.7 могли вносить разделители хаотично: использовать обратный слеш \, ставить пробелы вокруг слеша (ИНН / КПП) или вообще не указывать КПП. В таких случаях простое склеивание строк в источнике не даст стопроцентного сопоставления.
Чтобы решить эту проблему, переопределим стандартный поиск в правиле конвертации объектов (ПКО) Контрагенты на стороне приемника. Разберем по шагам, как написать алгоритм поиска в обработчике «ПоляПоиска»:
СсылкаНаОбъект и прекращаем стандартный поиск, установив флаг ПрекратитьПоиск = 1.Посмотрим на пример реализации такого алгоритма для платформы 1С 7.7:
// Создаем объект справочника для поиска в базе 7.7
СпрКонтр = СоздатьОбъект("Справочник.Контрагенты");
СтрокаПоиска = СокрЛП(СвойстваПоиска["ИНН"]);
// 1. Попытка прямого поиска по исходному значению
Если СпрКонтр.НайтиПоРеквизиту("ИНН", СтрокаПоиска, 1) = 1 Тогда
СсылкаНаОбъект = СпрКонтр.ТекущийЭлемент();
ПрекратитьПоиск = 1;
Иначе
// 2. Попытка поиска с заменой обратного слеша на прямой
АльтернативнаяСтрока = СтрЗаменить(СтрокаПоиска, "\", "/");
Если СпрКонтр.НайтиПоРеквизиту("ИНН", АльтернативнаяСтрока, 1) = 1 Тогда
СсылкаНаОбъект = СпрКонтр.ТекущийЭлемент();
ПрекратитьПоиск = 1;
Иначе
// 3. Дополнительно можно попробовать очистить пробелы внутри строки
АльтернативнаяСтрока = СтрЗаменить(СтрокаПоиска, " ", "");
Если СпрКонтр.НайтиПоРеквизиту("ИНН", АльтернативнаяСтрока, 1) = 1 Тогда
СсылкаНаОбъект = СпрКонтр.ТекущийЭлемент();
ПрекратитьПоиск = 1;
КонецЕсли;
КонецЕсли;
КонецЕсли;
Важное требование платформы 1С 7.7: Быстрый поиск с помощью метода НайтиПоРеквизиту сработает только в том случае, если в конфигураторе у реквизита ИНН справочника Контрагенты включено свойство «Отбор по реквизиту» или «Сортировка». Если индексация отключена, поиск завершится ошибкой или не вернет результат.
Часто при ручном вводе данных в 1С 7.7 или при копировании из сторонних документов в строку ИНН попадают невидимые символы, такие как неразрывный пробел (символ с кодом 160). Для платформы они выглядят как обычные пробелы, но обычная функция СокрЛП() их не удаляет.
Чтобы исключить влияние таких символов на результат сопоставления, рекомендуется перед сравнением или поиском выполнять их принудительную замену на стандартные пробелы (с последующим удалением через СокрЛП):
// Очистка от неразрывных пробелов на стороне 1С 7.7
СтрокаПоиска = СтрЗаменить(СтрокаПоиска, Симв(160), " ");
СтрокаПоиска = СокрЛП(СтрокаПоиска);
Проанализируем еще одну частую проблему на практике. Иногда в базе-приемнике один и тот же контрагент заводится несколько раз (например, старая карточка помечается на удаление, а для новой задается другое название, но ИНН остается прежним). Если сопоставлять данные только по ИНН/КПП, правила конвертации могут привязать новые документы к помеченной на удаление или неактуальной карточке.
В таких сложных случаях эффективнее использовать комбинированный поиск. Например, сначала искать точное совпадение по связке «Наименование + ИНН», и только при отсутствии результатов переходить к поиску по ИНН/КПП. Это позволит избежать перекрестного затирания данных и минимизирует появление логических ошибок в учете.