Введение
Всем привет! Давайте поговорим о таком объекте конфигурации — как "План обмена".
В этой статье я хочу поделиться своим опытом по работе с этим объектом, расскажу, с какими обменами я сталкивался за свою практику — начнем с самых простых вещей — автоматической регистрации в плане обмена, а закончить постараюсь применением интересных возможностей 1С для регистраций объектов к обмену.
Здесь я не буду рассматривать такие вещи, как конвертация данных, перенос объектов из одной конфигурации в другую. Начнем с того, как нам вообще зарегистрировать объекты к обмену, опишем и обсудим способы.
В статье ориентируюсь на популярную конфигурации УНФ (Управление нашей фирмой 1.6) и немножечко затронем обычные формы конфигурации УПП (Управление производственным предприятием 1.3).
В обоих случаях я буду использовать платформу 1с предприятия 8.3.15.1700.
Итак, давайте начнем:
Автоматическая регистрация
Как я написал выше — предлагаю начать с самого простого — это создание самого плана обмена и добавление в него объектов конфигурации к обмену. Для этого, заходим в конфигуратор, находим в "общих" — "планы обмена".
Создаем новый план обмена. Пусть будет называться "Товары и услуги" (ТоварыИУслуги). Нажимаем кнопочку "Состав" в нем — и добавляем единственный объект — справочник "Номенклатура". Галочка "Авторегистрация" включена.
Собственно, практически все. Все записи справочника "Номенклатура" в конфигурации будут регистрироваться в объекте конфигурации "План обмена" в созданном узле.
Использовать предопределенный узел (с точкой) нельзя, но присвойте ему уникальный код. Поэтому, давайте создадим узел (добавим ему код) в этом плане обмена и проверим, как проходит регистрация и что там регистрируется.
Чтобы посмотреть, что регистрируется в узле, например, в УНФ есть такая обработка "Регистрация изменений для обмена данными" (вообще любой типовой конфигурации существует такая обработка). В ней нужно выбрать узел плана обмена (у нас это будет созданный ранее узел плана обмена (не предопределенный)).
Рис.1. Узлы плана обмена "Товары и услуги".
Так, выбрали узел и смотрим, на какие объекты он "настроен". В нашем случае — это только "Номенклатура". У нас видно, что к обмену зарегистрировано более 1100 объектов. Нажав на объект "Номенклатура" — можно посмотреть справа какие объекты зарегистрированы к обмену (это касается УНФ). Картина такая:
Рис.2. Обработка регистрации/отмены регистрации изменений для узла обмена (УНФ 1.6).
Так же можно добавить объекты к обмену или удалить из обмена — это кнопки "Зарегистрировать" и "Отменить регистрацию" соответственно.
В конфигурациях на обычных формах данная обработка выглядит по-другому. На мой взгляд, "классическая" обработка более удобна (привычна). Привожу ее вид для конфигурации УПП 1.3.
Рис.3. Регистрация изменений для обмена данными для УПП 1.3 (УТ 10.3).
На этом закончим раздел "Автоматическая регистрация". Здесь нет никаких сложностей. "Запись" в узел идет автоматом. Теперь, рассмотрим более сложный способ регистрации объектов конфигурации — "по подписке".
Регистрация через подписку. Запрет авторегистрации
Теперь давайте рассмотрим такой пример. Нам нужно регистрировать товары в одном узле, а услуги в другом. Разберем этот пример.
Первое, что мы сделаем, добавляем в конфигурацию новый объект — план обмена "ВыгрузкаНоменклатуры". В состав плана обмена добавляем справочник "Номенклатура", запрещаем авторегистрацию — как на рисунке:
Рис.4. Запрет авторегистрации в новом плане обмена.
Запускам предприятие, выбираем созданный план обмена и создаем там 2 узла "ВыгУслуг" и "ВыгТоваров" как на рисунке:
Рис.5. Создание узлов в плане обмена.
В узел "ВыгТоваров" (002) будем выгружать номенклатуру с типом "Запас", а в "ВыгУслуг" (001) — выгружаем услуги. Для этого создаем подписку на событие "РегистрацияСправочникаВУзле" с типом "ПриЗаписи" и прописываем на нее такую процедуру:
Процедура ПриЗаписиСправочника(Источник, Отказ) Экспорт
Если Источник.ТипНоменклатуры = Перечисления.ТипыНоменклатуры.Услуга Тогда
УзелОбмена = ПланыОбмена.ВыгрузкаНоменклатуры.НайтиПоКоду("001"); // узел услуг
Если Источник.ПометкаУдаления Тогда
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена,Источник);
Иначе
ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена,Источник);
КонецЕсли;
ИначеЕсли Источник.ТипНоменклатуры = Перечисления.ТипыНоменклатуры.Запас Тогда
УзелОбмена = ПланыОбмена.ВыгрузкаНоменклатуры.НайтиПоКоду("002"); // узел запасов
Если Источник.ПометкаУдаления Тогда
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена,Источник);
Иначе
ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена,Источник);
КонецЕсли;
Иначе
КонецЕсли;
КонецПроцедуры
Теперь, проверим как работает. Заходим в справочник "номенклатуру", выбираем с типом "запас" и записываем. Смотрим, что и где зарегистрировалось в узлах обмена:
Рис.6. Регистрация товаров в "ВыгТоваров".
Если записываем номенклатуру с типом "услуга", находим ее в узле "ВыгУслуг".
Рис.7. Регистрация услуг в узле "ВыгУслуг".
Операция "Пометить на удаление" отменяет регистрацию объекта в узле. Все работает — запасы падают в запасы, а услуги — в услуги. Так же можно добавлять объекты в узел плана обмена по любому условию.
Обмен через регистр сведений
Так же в этой статье я предложу еще такой вариант решения — регистрация документов к обмену через регистр сведений. По своему опыту — рассмотрим на примере конфигурации УНФ 1.6 (хотя, это в свое время хорошо использовалось в УПП).
Первое, что мы должны сделать — в конфигурации создать дополнительный регистр сведений "ДокументыДляВыгрузкиВБухгалтерскуюПрограмму" — пусть называется так. В нем создадим 3 измерения: Организация (тип Организация), ТипДокумента (тип Строка(200)) и ДокументСсылка (тип ДокументСсылка).
На рисунке это выглядит вот так:
Рис.8. Структура регистра сведений "ДокументыДляВыгрузкиВБухгалтерскуюПрограмму".
Теперь, нам нужно "отправлять документы" в этот регистр, если документ изменен. Для этого я опять воспользуюсь классным механизмом "Подписок на события".
Вернее, я создам одну подписку на событие "ДобавлениеВРегистр" по всем документам (ДокументСсылка) на действие "ПриЗаписи". Ознакомится с материалом по подпискам на события можно здесь, а готовый пример системы подписок можно скачать здесь. В коде я не буду "обходить" ситуацию, где у документа отсутствует реквизит "Организация".
Итак, подписка создана. Процедура подписки указана. Она достаточна простая. Привожу ее:
Процедура ПриЗаписиДокументаВРегистр(Источник, Отказ) Экспорт
Статус = ОпределитьСтатусДокумента(Источник);
Если Источник.ПометкаУдаления Тогда
Если Статус Тогда
МенеджерРегистра = РегистрыСведений.ДокументыДляВыгрузкиВБухгалтерскуюПрограмму;
НаборЗаписейРегистра = МенеджерРегистра.СоздатьНаборЗаписей();
НаборЗаписейРегистра.Отбор.ДокументСсылка.Установить(Источник.Ссылка);
НаборЗаписейРегистра.Очистить();
НаборЗаписейРегистра.Записать();
КонецЕсли;
Иначе
Если НЕ Статус Тогда
МенеджерЗаписи = РегистрыСведений.ДокументыДляВыгрузкиВБухгалтерскуюПрограмму.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Активность = Истина;
МенеджерЗаписи.ДокументСсылка = Источник.Ссылка;
МенеджерЗаписи.Организация = Источник.Организация;
МенеджерЗаписи.ТипДокумента = Строка(ТипЗнч(Источник.Ссылка));
МенеджерЗаписи.Записать(Истина);
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Теперь, напишу пояснения. Первым шагом мы определяем есть ли уже документ-источник в нашем регистре сведений при помощи простой функции ОпределитьСтатусДокумента():
Функция ОпределитьСтатусДокумента(ДокументОбъект) Экспорт
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| РегистрСостояний.ДокументСсылка КАК Ссылка
|ИЗ
| РегистрСведений.ДокументыДляВыгрузкиВБухгалтерскуюПрограмму КАК РегистрСостояний
|ГДЕ
| РегистрСостояний.ДокументСсылка = &Документ";
Запрос.Параметры.Вставить("Документ",ДокументОбъект.ссылка);
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() тогда
Возврат Истина;
Иначе
Возврат Ложь;
КонецЕсли;
КонецФункции
Затем, определяем — имеет ли пометку удаления наш "Источник" и, в зависимости от этого, — либо создаем запись в регистре для него, либо удаляем документ из регистра (посмотрите как можно работать с МенеджеромЗаписи еще).
Рабочий заполняемый регистр выглядит вот так (все работает — документы добавляются/удаляются из этого регистра):
Рис.9. Содержимое регистра сведений для выгрузки в бухгалтерскую программу.
Схема достаточна простая и реализуется, как мы все видим, одним регистром, одной подпиской и двумя функциями. Кстати, нужно указать, что созданные функции я поместил в отдельном общем модуле ФункционалВнешнийМенеджерСервер, в котором установлены галки "Сервер", "Вызов сервера", "Привилегированный".
К сожалению, на текущий момент, в расширение этот функционал не перенести — ввиду отсутствия поддержки механизма "Подписок на события" в расширениях. Но, в будущих релизах платформы разработчики обещают добавить подписки.
Заключение и выводы
В этой статье я привел три основных "базовых" наиболее частых метода регистрации объектов конфигурации к обмену, которые встречались по собственному опыту работы. На каждый метод я постарался привести максимально понятный пример и дать пояснение по работе метода.
Собственно, вот они:
1.Автоматическая регистрация объектов к обмену (самая простая, подойдет для новичков или для создания "быстрых регистраций к обмену").
2."Ручная" регистрация объектов к обмену через план обмена (чуть сложнее, подойдет для механизмов "с условием" на уровне отправки в узел плана обмена).
3.Регистрация объектов к обмену через регистр сведений (вот этот метод я бы выбрал, если бы не хотел "ломать" то, что создано до меня, аккуратно внедрил собственную систему регистрации документов к обмену на основе регистра, здесь и фильтр по обмену прикрутить очень просто).
Еще один важный момент — не забывайте про права пользователей и роли доступа, когда вы будете создать новый план обмена или регистр с подпиской…
Если вам понравилась эта статья и ее изложение, если вы захотите ее поддержать — буду только рад этому. В свою очередь, я буду рад подготовить более интересные темы из своего опыта — "написание правил для конвертации данных" или "получение данных в документ из внешних хранилищ информации (напрямую с сайта или фтп)".
Спасибо, что дочитали статью до конца. Всем привет.
Предыдущие материалы
Так же, прошу посмотреть мои предыдущие статьи:
Работа с механизмом отладки 1С. Базовые настройки
Методика независимой системы "Подписки на события"
Подсистема "Подписки на события" (продолжение)
Лайфхак работы с СКД. Собираем отчет
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Так и остался нераскрытым смысл данной статьи.
Использовать регистры сведений вместо планов обмена, чтобы подменить ими планы обмена вообще дурной тон. Более того приведенный пример ПриЗаписиДокументаВРегистр вообще никак не отработает смену организации в документе.
Никто не запрещает вмешаться в модуль существующей подписки на событие, благо их разнообразие в типовых конфигурациях покрывает практически все типы объектов и необходимые события.
(1) Для каждой задачи — свои решение. Из планов обмен можно получить только текущую версию объекта.
А если нужно иметь все версии для обмена, то как раз удобно использовать связку подписка -> регистр сведений и там хранить версию объекта
(2) тут вроде решили обсудить обмены? Для хранения версий есть штатный (для конфигураций на БСП) регистр сведений ВерсииОбъектов, для обмена версиями достаточно данный регистр добавить в план обмена. План обмена гарантирует доставку из источника в приемник. Именно в этом его огромное достоинство. При любых попытках реализовать обмен иначе (как тут третий вариант — через регистр) по сути нужно разрабатывать
велосипедфункционал обмена данными заново.(3)
Верно ли я Вас понял, что он гарантирует включение в себя ссылок на измененные объекты. Т.е. из источника в план обмена. Именно это направление.
Далее читаем план обмена обработкой и передаём сведения в получателя (другая база, файл или иное программное обеспечение), то надежность передачи из плана обмена в приемник уже не зависит от него.
(3) Ухо резануло:
Я так и сделал.
Если предметно: ЗаявкаРасходДС меняет свой статус много раз в день, обмен — раз в сутки. И план обмена — не выход, в вот подписка с регистром версий хорошо подходит
(3)Простите, но сам план обмена ничего подобного не гарантирует.
(6) сам план обмена, как объект метаданных, конечно не гарантирует. Подразумевался штатный механизм обмена, который снимает с регистрации в источнике объекты только в случае успешного приема сообщения в приемнике.
(4) с регистрации в плане обмена сведения снимаются не после передачи, а после получения ответа о том, что все сведения были загружены.
В объекте конфигурации «План обмена» ничего подобного не регистрируется 😉
После проектирования и разработки многочисленных интеграций с системами, не связанных с 1С, пришел к выводу, что планы обмена неудобны. Они удобны при синхронизации между 1С.
(9)
в узле
(5) А поясните тогда…
Вот в течении дня вы 10 раз туда-сюда переткнули статус документа. Объект к концу дня имеет какой-то конечный(?) статус и подлежит выгрузке, т.к. зареган в узле ПО. И вот он в своём текущем виде выгружается.
А зачем тут РС нужен?
Возможно, у вас методологически некорректное решение? Следует ввести признак «заявка рассмотрена» или «рассмотрение завершено», который ставится окончательно и заявку более невозможно скорректировать никому. И регистрировать в узле ПО только такие заявки.
(10) Реализовывал обмены с собственными сайтами клиентов и сторонними сайтами по веб-сервисам через планы обмена. Всё работало удобно и корректно.
Можете уточнить, что конкретно неудобно?
(11)
В таблице регистрации изменений. А не в «узле».
А как «Пометку удаления» тогда передать?
(11)
В самом узле тоже не регистрируются записи справочника «Номенклатура». Они регистрируются в другом месте.
(13) Да корректно можно сделать по любому. Тут в простоте..
Если говорим о сайтах. То возьмем товар. У товара есть несколько ключевых данных, основанных на регистрах:
1) Его цена
2) Его остаток
3) Его значение свойства
И напрашивается алгоритм: изменилось что нить — делаем ручную регистрацию товара. Итого имеем: изменился изменилась цена товара — в планах будет товар. Но не понять, что конкретно изменилось. И поэтому, когда что то изменилось — выгружаем всю информацию о товарах и это долго, что весьма критично для высоконагруженных сайтов. Нужно выгружать только то, что изменилось. Изменилась цена — выгружаем только цену.. Более того, необходим момент времени регистрации.
Еще такой момент, регистрация в планах хранится в разрезе узла плана, в регистре хранится в разрезе сайтов.
Еще такой момент, товар в 1С — может иметь несколько разных сущностей во внешней системе..
(17)
Один план, один сайт. Нет?
Про правила регистрации то же как то не слова….
(18) Почему 1 план? 1 узел — выгрузка товаров раз в день. 2 узел — выгрузка цен раз в час, 3 узел — выгрузка остатков раз в 15 минут. 4 план — обмен заказами.
Это я еще не говорю, что в 1 узле может быть несколько настроек и выгрузок в разные инфоблоки(commerce ML)
(18) можно сделать и в одном плане, но возникает вопрос с там, как хранится изменение. Да и настройки монструозные получаются, да и поддержка. На практике проще разделять на разные узлы. Каждый узел — своя операция обмена.
(17) Если так делать, то да, глупо как-то. Я регистрировал наборы записей РС ЦеныНоменклатуры и понимал, что нужно выгрузить именно цену товара.
(22) Ну так реализован типовой обмен с сайтом в конфигурациях 1С.
В вашем примере бывают проблемы, когда документ удалили, не понять, цена какого товара изменилась..
Да понятно, что можно использовать план обмена, но когда хочешь сделать шаг влево или вправо от шаблона использования — начинаются костыли. Я на них ни раз столкнулся и понял, ну их нафиг. Регистр сведений более универсальный.
no comments
(12) Кто и когда изменил статус
(18) Он неправильно изначально написал. Регистрация в планах хранится по узлам. А каждый узел привязан к конкретному сайту. Вообще нет проблем.
(20) Зачем это делать в одном узле? Если даже у вас РИБ, то делают разные узлы. Куда-то дошло, куда-то нет. Что делать с регистрацией? Очищать выгруженные или нет? Одна интеграция с одной целевой системой — один узел одного ПО.
(23)
А как же регистрация удаления? Попробуйте в тестовой базе и удивитесь. Берём из набора записей удалённого документа номенклатуру, цепляем к ней цену на текущий момент и выгружаем. Всё работает корректно.
(25) А причём тут обмены? Если речь про историю изменений, то есть однотипный платформенный механизм и, если платформа старая, то целая подсистема в БСП.
(8) понял. спасибо!
(17) вебхуки просто идеальны для решения такой задачи, минус вебхуков — только необходимость разработки и подстройки под ту или иную CRM
(29) В Базе-приемнике нужно прогнать все состояния заявки по бизнес-процессу
(32) Всё верно. Используйте целевую подсистему и подключите её к плану обмена.
Совсем не учтен важный момент — документ передается с движениями или нет. При авторегистрации все делается автоматом, При ручной регистрации все надо прописывать в коде. Причем при распроведении прописывать по ВСЕМ движениям документа (даже если какие-то движения вроде как и не используются). Ах да, если для документа есть последовательность — дополнительное внимание.
ps. в совсем уж тяжком случае объекты зарегистрированные для обмена можно посмотреть через запрос типа
Минус — нельзя сразу увидеть объекты всех типов.
В стандартном конструкторе запроса чтобы увидеть таблицы объектов на обмен необходимо на вкладке «Таблицы и поля» нажать на кнопку «Отображать таблицы изменений» (слева вверху).