При настройке обмена данными между различными конфигурациями 1С мы часто сталкиваемся с ситуацией, когда одни и те же сущности описаны разными типами метаданных. Классический пример — ставки НДС. В старых конфигурациях, таких как Комплексная автоматизация 1.1, ставки НДС представлены объектом Перечисление. В современных решениях, например Управление нашей фирмой 1.6, это уже полноценный Справочник. В этой статье мы подробно разберем, как правильно сопоставить эти объекты с помощью инструмента Конвертация данных 2.1.
Основная проблема заключается в архитектурном различии объектов. Значения Перечисления задаются в конфигураторе и не имеют внутреннего идентификатора (GUID), который можно было бы сопоставить с GUID элемента Справочника. Кроме того, наименования перечислений в коде (идентификаторы) часто не совпадают с тем, что пользователь видит в справочнике базы-приемника. Нам необходимо создать гибкую систему поиска, которая позволит программе однозначно определить, какому значению перечисления соответствует конкретный элемент справочника.
Этот способ предложил автор темы, и он является одним из самых простых в реализации, если вы готовы немного подправить данные в базе-приемнике или привести их к общему знаменателю. Рассмотрим этот алгоритм по шагам:
СтавкиНДС к виду, который соответствует именам значений перечисления в источнике (например, вместо "20%" сделайте "НДС20").СтавкаНДС в документе (например, ПриходнаяНакладная) в обработчике ПередВыгрузкой пропишите код, который будет передавать строковое представление значения:
Значение = Строка(Источник.СтавкаНДС);
СтавкиНДС обязательно снимите флаг "Искать объект приемника по внутреннему идентификатору объекта источника". Поскольку у перечисления нет GUID, поиск по нему приведет к созданию дублей или ошибкам.Если вы не хотите менять наименования в справочнике базы-приемника (например, там уже заполнены значения "20%", "20% / 120%", "Без НДС"), мы можем использовать программную обработку соответствий. Это более надежный метод, не требующий изменения данных в рабочих базах.
В ПКС документа (где переносится поле СтавкаНДС) в обработчике ПередВыгрузкой пропишем явное соответствие:
Если Источник.СтавкаНДС = Перечисления.СтавкиНДС.НДС20 Тогда
Значение = "20%";
ИначеЕсли Источник.СтавкаНДС = Перечисления.СтавкиНДС.НДС20_120 Тогда
Значение = "20% / 120%";
ИначеЕсли Источник.СтавкаНДС = Перечисления.СтавкиНДС.БезНДС Тогда
Значение = "Без НДС";
Иначе
Отказ = Истина; // Если значение не определено, можем пропустить выгрузку
КонецЕсли;
При такой настройке в ПКО справочника СтавкиНДС поиск должен осуществляться по полю Наименование. Система возьмет строку из переменной Значение и попытается найти элемент с точно таким же именем в справочнике приемника.
Давайте проанализируем ситуацию глубже: в справочниках НДС современных систем часто есть числовой реквизит Ставка (тип Число). Это более стабильный параметр для поиска, чем строка наименования, которая может содержать лишние пробелы или спецсимволы.
Для реализации этого подхода выполните следующее:
СтавкиНДС создайте ПКС для числового реквизита.ПередВыгрузкой этого ПКС напишите код, который преобразует перечисление в число:
Если Источник = Перечисления.СтавкиНДС.НДС20 Тогда
Значение = 20;
ИначеЕсли Источник = Перечисления.СтавкиНДС.НДС10 Тогда
Значение = 10;
// и так далее
КонецЕсли;
Рассмотрим ситуацию, когда сопоставление должно быть еще более сложным. В ПКО справочника СтавкиНДС можно использовать обработчик Поля поиска. Этот метод позволяет написать произвольный запрос к базе-приемнику прямо в момент загрузки данных.
Алгоритм работы системы будет следующим:
Поля поиска.СвойстваПоиска.Справочники.СтавкиНДС.НайтиПоНаименованию или запрос к таблице).СсылкаНаОбъект.Проанализируем несколько критических моментов, которые могут сорвать процесс конвертации:
1. Различие между "Без НДС" и "0%": Будьте предельно внимательны. В бухгалтерии это разные сущности. Убедитесь, что ваше правило корректно разделяет эти значения перечисления, так как в справочнике приемника это будут два разных элемента. Ошибка в этом поле приведет к некорректному заполнению книги покупок/продаж.
2. Автоматическое создание элементов: Если в базе-приемнике справочник еще не заполнен, в ПКО должна стоять галочка "Генерировать новый номер или код, если он не задан". Без этого программа может выдать ошибку при попытке создать новый элемент справочника, так как в 1С код обычно является обязательным полем.
3. Отключение поиска по ГУИД: Как мы уже выяснили, это обязательное условие. При обмене "Перечисление -> Справочник" попытка поиска по внутреннему идентификатору всегда будет возвращать пустой результат, что приведет к созданию дублей при каждой новой выгрузке.
4. Использование "Пустого" источника: Иногда удобно создать ПКО, где Источник не указан. Тогда в ПКС документа мы просто передаем в Значение строку, а в ИмяПКО указываем наше правило для справочника. Это позволяет сделать правила более универсальными и не привязанными к конкретному перечислению источника.
Таким образом, комбинируя программные обработчики и настройки поиска по наименованию, мы можем реализовать надежный перенос данных между объектами разного типа, сохраняя целостность учета в системе-приемнике.