1С универсальный формат обмена

Содержание
  1. Описание формата
  2. Обмен данными с программами «1С»
  3. Предварительная настройка на стороне «1С»
  4. Формат файлов обмена
  5. Механизм квитирования
  6. Обмен через веб-сервис
  7. Обмен через другие каналы
  8. Заключение
  9. Ресурсы
  10. Новый стандарт 1С для обменов Полное изучение за 2 недели
  11. Новая технология не имеет почти ничего общего с предыдущими
  12. Реальные отзывы реальных людей
  13. Что Вы изучите (содержание курса)
  14. Занятие 1. Описание технологии и подготовка к переносу данных
  15. Занятие 2. Простые переносы объектов
  16. Занятие 3. Простые переносы объектов. Написание обработчиков
  17. Занятие 4. Механизмы, лежащие в основе технологии: XML, XDTO, Универсальный формат
  18. Занятие 5. Конвертация объектов, отличающихся от объектов формата
  19. Занятие 6. Перенос объектов вместе с дополнительными данными
  20. Занятие 7. Идентификация
  21. Занятие 8. Параметры конвертации и алгоритмы
  22. Занятие 9. Произвольная выборка данных и задачи, ею решаемые
  23. Занятие 10. Обработчики событий на стороне отправки
  24. Занятие 11. Обработчики событий на стороне получения
  25. Занятие 12. Регистрация объектов к выгрузке
  26. Занятие 13. Настройка обмена между типовыми конфигурациями
  27. Примеры из курса
  28. Объем материалов курса
  29. Формат курса, поддержка
  30. Актуальность курса
  31. Стоимость курса

Для облегчения интеграции с программными продуктами фирмы «1С» разработан формат обмена данными EnterpriseData. Формат основан на XML и является бизнес-ориентированным — описанные в нем структуры данных соответствуют бизнес-сущностям (документам и элементам справочников), представленным в программах «1С», например: акт выполненных работ, приходный кассовый ордер, контрагент, договор и т. п. Это делает формат интуитивно понятным и легким в использовании.

Формат EnterpriseData предназначен для обмена данными внутри компании (в том числе между разнородными и территориально удаленными информационными системами) и призван покрыть все сферы деятельности предприятия — финансы, производство, закупки и продажи, складские операции и т. п.

Описание формата

Версия 1.0.1 формата включает в себя описание 94 типов бизнес-сущностей из различных областей бизнеса. Формат является расширяемым — фирма «1С» будет добавлять в него описание новых бизнес-сущностей и расширять существующие сущности новыми полями. Поддержка формата в продуктах фирмы «1С» обеспечивает совместимость снизу вверх — все программы сторонних производителей, обменивающихся данными в формате EnterpriseData с продуктами «1С», при выходе новых версий формата корректно продолжат работу.

Формат предназначен для обмена информацией между любыми информационными системами: он не зависит от особенностей собственного программного обеспечения или структур информационных баз, которые участвуют в обмене и не содержит в себе явных ограничений использования.

  • «1С:ERP Управление предприятием 2.0»,
  • «Бухгалтерия предприятия», редакция 3.0,
  • «Бухгалтерия предприятия КОРП», редакция 3.0,
  • «Розница», редакция 2.0,
  • «Управление торговлей базовая», редакция 11,
  • «Управление торговлей», редакция 11,
  • «Зарплата и управление персоналом КОРП», редакция 3.

Обмен данными с программами «1С»

Предварительная настройка на стороне «1С»

  • веб-сервис,
  • файловый обмен через каталог,
  • файловый обмен через FTP,
  • обмен через электронную почту.

В случае обмена через веб-сервис стороннее приложение будет инициировать сеанс обмена данными путем вызова соответствующих веб-методов приложения «1С». В остальных случаях инициатором сеанса обмена будет приложение «1С».

  • по расписанию (с заданной периодичностью);
  • вручную; пользователь должен будет вручную запускать синхронизацию каждый раз, когда это ему потребуется.

Формат файлов обмена

В ходе синхронизации приложения «1С» и сторонние приложения обмениваются сообщениями — XML-файлами определенной структуры. Эти файлы состоят из двух секций — и . Секция содержит сообщение-квитанцию (о ней ниже), а — информацию об измененных бизнес-сущностях в формате EnterpriseData.

  1. ExchangePlan. Строка, определяющая порядок обмена данными на стороне «1С». Для обмена с внешними приложениями всегда равна значению «СинхронизацияДанныхЧерезУниверсальныйФормат», для обмена между приложениями «1С» может настраиваться. Подробности для настройки при обмене между приложениями «1С» — в документации «1С».
  2. To. Уникальный код приложения, с которым осуществляется обмен (см. Предварительная настройка на стороне «1С»).
  3. From. Код приложения — источника данных. В случае если это приложение «1С», код по умолчанию будет заполнен автоматически (УП для «1С: Управление предприятием», БП для «1С: Бухгалтерия предприятия» и т. д.), но его значение можно будет изменить вручную в мастере настройки.
  4. MessageNo. Номер последнего сообщения, отправленного из «1С» в приложение.
  5. ReceivedNo. Номер последнего сообщения, принятого «1С» от приложения

Если сообщение идет в обратном направлении — от стороннего приложения в приложение «1С», стороннее приложение должно соответствующим образом заполнить секцию .

Приложения «1С» ведут учет отправленных и полученных сообщений синхронизации и ожидают того же от сторонних приложений. Для чего это делается — изложено ниже.

Механизм квитирования

Приложения «1С» в ходе синхронизации передают только информацию об изменениях, произошедших с бизнес-сущностями со времени последней синхронизации (чтобы минимизировать объем передаваемой информации). При первой синхронизации приложение «1С» выгрузит все бизнес-сущности в формате EnterpriseData в XML-файл (поскольку все они являются «новыми» для внешнего приложения). Следующий шаг за сторонним приложением –оно должно обработать информацию из XML-файла и при следующем сеансе синхронизации поместить в секцию информацию, что сообщение от «1С» за определенным номером успешно принято (поместить в поле ReceivedNo номер полученного от «1С» сообщения). Сообщение-квитанция является для приложения «1С» сигналом, что все бизнес-сущности успешно обработаны внешним приложением и информацию о них передавать больше не нужно. Помимо квитанции XML-файл от стороннего приложения также может содержать данные для синхронизации (в секции ).

После получения сообщения-квитанции приложение «1С» помечает все изменения, переданные в предыдущем сообщении, как успешно синхронизированные. Лишь несинхронизированные изменения в бизнес-сущностях (создание новых, изменение и удаление существующих) будут отправлены во внешнее приложение при следующем сеансе синхронизации.

При передаче данных от внешнего приложения в приложение «1С» картина меняется на обратную. Приложение должно заполнить секцию соответствующим образом, а в секцию поместить бизнес-данные для синхронизации в формате EnterpriseData.

Приложение «1С» после обработки файла сформирует XML-файл, который будет содержать сообщение-квитанцию и новые данные для синхронизации со стороны «1С» (если такие есть со времени последнего сеанса синхронизации).

Обмен через веб-сервис

При использовании веб-сервиса инициатором сеанса обмена выступает стороннее приложение. Для получения данных от приложения «1С» ему нужно вызвать веб-метод GetData, передав в качестве параметров метода уникальный код приложения, введенный на этапе настройки. В ответ «1С» вернет файл, содержащий данные о бизнес-сущностях в формате EnterpriseData[1]. Формат файла описан выше.

Чтобы передать данные в «1С», приложение должно вызвать веб-метод PutData, передав как параметры уникальный код приложения и заархивированный файл в описанном выше формате.

Обмен через другие каналы

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

Читайте также:  Чему равна вероятность невозможного события

Заключение

Набор сценариев интеграции с использованием формата EnterpriseData широк. Это и обмен данными в пределах одной организации, например, передача данных в «1С: Бухгалтерию» из других приложений для ведения целостного учета, или обмен данными между центральным офисом и удаленными складами. Подходит формат и для обмена данными между разными организациями.

В планах «1С» — дальнейшее развитие формата EnterpriseData и его поддержка во все большем количестве приложений, разрабатываемых фирмой.

Ресурсы

[1] В реальности ситуация чуть сложнее. Поскольку размер передаваемой через веб-сервисы информации ограничен, приложению нужно будет получать от «1С» файл в виде архива, разделенного на части. В случае передачи файла от стороннего приложения в приложение «1С» приложению нужно будет заархивировать файл с данными и передать архив по частям, используя методы веб-сервиса.

Обмен через универсальный формат широко используется в типовых конфигурациях. Для ознакомления есть хорошая статья //i.doc-lvv.ru/public/695523/, также множество различных курсов, в которых разложены основные моменты по работе с правилами конвертации, синхронизации объектов метаданных.

Основной принцип создания "нестандартных" правил обмена заключается в доработке модуля "МенеджерОбменаЧерезУниверсальныйФормат" (в различных конфигурациях название может немного отличаться). Но что делать, если в компании участвуют несколько баз данных – стандартных, самописных (неважно), между которыми идет активный обмен данными EnterpriseData – и на каждый узел обмена могут действовать свои специфические правила?

В данном случае удобно использовать механизм расширений конфигурации – и если требуется организовать специфичные правила обмена, тогда в конфигурации создается отдельное расширение о обмену.

Рассмотрим пример передачи данных из базы УТ 11.3 в идентичную по структуре базу данных "Дочерняя УТ 11.3".

Постановка задачи: в основной базе данных производятся продажи товаров специфическому контрагенту, который является "дочерней фирмой" по отношению к основной. Необходимо реализовать "одностороннее" правило обмена "Реализации товаров и услуг -> Поступления товаров и услуг" по контрагенту с фиксированным ИНН.

ЦБ – база-источник УТ 11.3, из которой идет выгрузка документов "Реализации товаров и услуг"

УТ – база приемник, в которой при обмене создаются "Поступления товаров"

ED – универсальный обмен (EnterpriseData)

В базе ЦБ создаются и проводятся "Реализации товаров" – и после проведения регистрируются в обмене ED, далее происходит обмен (через фоновое задание, либо вручную через каталог обмена). В при этом документ "Реализация товаров" должен "превратиться" в "Поступление товаров и услуг", а контрагент и организация "поменяться местами".

Как настраивать синхронизацию данных по плану обмена описано не будет – для этого существует множество различных статей. Переходим непосредственно к созданию правил обмена.

Предположим, что у нас настроен обмен, при котором главный узел организации-источника имеет код "ЦБ", а узел приемника код "УТ".

Для начала создадим расширение конфигурации: назовем его, для примера "РасширениеОбмен" – и добавим модули, которые нам нужны для решения задачи.

1.Установка активного узла обмена в параметре сеанса. К сожалению, в процессе обмена не всегда можно получить активный узел, для которого происходит обмен. В процессе самого обмена данными структура данных "КомпонентыОбмена", содержащая все настройки обмена ED (в том числе ссылку на узел обмена) доступна не в каждой процедуре при обмене данными: например, при непосредственном заполнении перечня правил обмена "МенеджерОбменаЧерезУниверсальныйФормат.ЗаполнитьПравилаОбработкиДанных" этой переменной в параметрах нет.

На этапе инициализации обмена данными установим код узла обмена в параметры сеанса:

2. Регистрация объектов. Также необходимо выделить перечень объектов, необходимых для регистрации в нужном нам узле универсального обмена. Это можно сделать, отредактировав правила регистрации объектов с использованием конфигурации "Конвертер 2.1", но в случае с расширением достаточно переопределить работу функции, разбирающей правила регистрации. В задании для нашего узла обмена нам нужны совсем "немногие" ссылки на объекты, остальное необходимо "отсечь".

Регистрироваться будет документ "Реализации товаров и услуг" и некоторые входящие в него ссылки: организация, контрагент, валюта, склад.

Также создана простая дополнительная процедура, которая "собирает" все подчиненные ссылки объекта в массив

3. Создание правил отправки данных. Все правила конвертации/отправки/получения данных находятся в модуле "МенеджерОбменаЧерезУниверсальныйФормат". Данный модуль содержит множество стандартных правил обмена – необходимо добавить к ним несколько "своих" правил конвертации. Новых правил можно выделить 3:

  • Реализация товаров, услуг -> Поступление товаров,услуг
  • Организации -> Контрагенты
  • Контрагенты -> Организации

Для создания правил можно использовать конфигурацию "Конвертер 3.0", но в целом можно просто использовать функции из типового модуля МенеджерОбменаЧерезУниверсальныйФормат как шаблоны методом "копи-пасты".

В результате получилась область с набором процедур следующего вида:

4. Создание правил получения данных. На каждое правило отправки данных должно быть введено хотя бы одно правило получения: выгруженный файл нужно каким-то образом загрузить в приемник.

Для создания правил получения можно воспользоваться конвертером 3.0, можно написать правила вручную (используя существующие примеры в модуле обмена).

4.1. Правило получения документа "Поступление товаров и услуг". В 1-ю очередь "разберемся" с основным правилом получения документа. Вариант идентификации тут подойдет "ПоУникальномИдентификатору", также необхдимы некоторые программные доработки по установке свойств из входящих данных. Например, "Номер входящего документа" в поступлении должен быть равен номеру реализации, также нужно указать вид операции поступления итд.

4.2. Правила получения контрагентов, организаций. На данном этапе сталкиваемся с 2-мя проблемами:

Типовые функции модуля "МенеджерОбменаЧерезУниверсальныйФормат" конфликтуют с функциями, которые создаются в расширении. Если для организации или контрагента уже существует хотя бы одно правило обмена – то система при получении найдет именно его и будет его использовать при конвертации. Нам это не подходит – тем самым необходимо программно удалять,либо изменять типовые правила получения.

Все (или почти все) типовые правила получения данных имеют вариант идентификации объектов "ПоУникальномуИдентификатору", что зачастую не подходит для решения задач обмена. В нашем примере в базах данных проводился независимый учет данных – тем самым при первом же обмене получим дублирование организаций, контрагентов итд.

Определим порядок поиска контрагентов и организаций: вариант идентификации "ПоПолямПоиска" и поля поиска "ИНН,КПП". Код обработки получения организаций, контрагентов примерно следующий:

4.3. Прочие правила получения. Проблема идентификации остается актуальной и для прочих ссылочных объектов: нам не нужны дубли номенклатуры итд. Для остальных объектов решено использовать вариант синхронизации "СначалаПоУникальномуИдентификаторуПотомПоПолямПоиска" – в этом случае идет поиск сначала по идентификатору, потом по полям поиска (если по идентификатору) не найдено. Также при этом используется специальный регистр соответствий ссылок, в котором можно задать соответствия ссылок объектов (подробно углубляться не будем, есть курсы и статьи, в которых это описано).

Читайте также:  Электроплита gorenje не работает духовка

5. Служебные функции по обмену данными. Чтобы указанные изменения были инициализированы – нужно доработать типовые функции по заполнению правил, отработке алгоритмов итд. иначе вышеописанные изменения не будут работать. Если вы используете конфигурацию "Конвертация данных 3.0" – то служебные функции будут автоматически созданы вместе с правилами конвертации и отправки, но можно без особого труда написать функции вручную (в нашем примере нестандартных правил немного).

Код дозаполнения правил конвертации:

Код дополнения правил обработки данных:

Выполнение спец.событий при обмене данными:

На этом доработки правил обмена практически завершены – осталось только очистить регистрацию выгруженных данных из узла плана обмена. В модуле "ОбменДаннымиXDTOСервер" допишем функцию по очистке регистрации, в случае если обмен был завершен без ошибок:

Завершающим шагом в режиме Конфигуратора добавляем в обе базы данных созданное расширение – оно должно работать как в источнике, так и в приемнике.

После создания расширения для начала можно "потестировать" обмен в режиме выгрузки файла в каталог, чтобы сразу не использовать прямое подключение к другой базе (вдруг на этапе выгрузки какие-то ошибки вскроются). Для примера проведем некий документ "реализации товаров и услуг" – после чего он должен появиться в списке зарегистрированных изменений для узла обмена "УТ":

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

Новый стандарт 1С для обменов
Полное изучение за 2 недели

Ничего похожего на КД 2.0…

  • Не нужно писать правила для каждой пары “Источник-Получатель”.
  • Не нужно их править при каждом обновлении.
  • Для групповых обменов больше не нужны десятки разных настроек.
  • Готовые метаобъекты для переносимых данных.

Все унифицируется. И на эту технологию уже переводятся ВСЕ типовые конфигурации 1С.

И специалист, который не владеет ею, рискует оказаться в ситуации «не смог выполнить стандартную задачу»

Начиная с принципа работы, заканчивая всей обвязкой.

Можете зайти на Мисту и посчитать темы по КД 3.0 в стиле «народ, кто-то в этом разобрался?»

Новый стандарт – это КД 3.0.

Ни в коем случае!

КД 2.0 будет поддерживаться, это независимый продукт, но 1С будет продвигать именно КД 3.0

Разработчики 1С решили, что унификация даст КД 3.0 преимущество в скорости и дальнейшей поддержке обменов.

Поэтому для сложных нестандартных случаев – продолжаем использовать КД 2.0. Но для типовых конфигураций (и для большинства обменов без космических задач) штатной будет именно КД 3.0

Главное – знать возможности обеих технологий. И не путать их, это может ударить по авторитету и по карману 🙂

Ага, в мире как раз не хватает заново изобретенных велосипедов 🙂

– Программист-“велосипедист”: Ну, там все не так однозначно. Нужно писать обмен, потом отладка, все дела, фиг знает сколько времени займет, может, неделю…

– Босс: Хорош гнать. У нас типовые конфы, всяко есть стандартные средства. И не тяни, у тебя два дня…

И у кого-то начнутся потуги 🙂

У обработок переносов через TXT / DBF / OLE и т.п. есть свои ниши.

Но использовать их для СТАНДАРТНЫХ задач – это явный признак непрофессионализма.

Иногда очень умелого, квалифицированного, гениального – но непрофессионализма.

Для кого этот курс

Обмены и переносы данных – одни из самых распространенных задач в мире 1С.

  • Любой ввод в работу новой системы – перенос.
  • Две и более информационные базы в компании – обмены.
  • Внешние системы и оборудования – обмены.

При этом обмены в типовых конфигурациях УЖЕ переводятся на технологию обмена через Универсальный формат.

Курс рассчитан на всех специалистов по 1С, которые могут столкнуться с задачами обменов – чтобы избавить от ненужных “экспериментов” и “внезапных” потерь данных.

Цели и задачи курса

Мы обучаем настройке обменов данными между различными конфигурациями на платформе 1С 8.3, используя новую технологию Конвертации Данных 3.0.

  • Структура 94 метаобъектов Универсального формата
  • Как работать с объектами Универсального формата и корректно их заполнять
  • Как использовать конфигурацию Конвертация данных 3.0 для простой и быстрой настройки правил
  • Типовые приемы настройки обменов с помощью КД 3.0
  • Как обходить проблемы, связанные с отсутствием в формате специальных объектов и свойств для переноса какой-либо дополнительной информации.

Новая технология не имеет почти ничего общего с предыдущими

В силу этого самостоятельное ее изучение может занять довольно продолжительное время.

Курс позволяет сэкономить примерно месяц (вместо самостоятельного экспериментирования).

И самое главное – поможет избежать рисков потери репутации из-за срывов сроков или потери данных вследствие некорректных настроек..

Реальные отзывы реальных людей

Курс позволил мне быстро разобраться во многих тонкостях технологии обмена через универсальный формат, а попутно освежить знания XML, XSD, XDTO.

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

Тем не менее, самостоятельно этот объем данных я бы не смог освоить за время курса. Я бы просто этот материал не нашел!
А набивать шишки путем проб и ошибок – это уже как минимум не профессионально.

Лучшие времена настали! Курс пройден. Огромное спасибо разработчику курса и нашему преподавателю за доступно изложенный материал, за раскрытие достаточно сложных (для меня) понятий, за сэкономленное время и нервы.

в курсе собран огромный объем информации, который невозможно найти самостоятельно. Получено четкое представление об особенностях КД 3.0, очень ценная информация об исправлении ошибок в общем модуле, не снимая конфигурацию с поддержки.

Что Вы изучите (содержание курса)

Занятие 1. Описание технологии и подготовка к переносу данных

  • Краткий обзор существующих технологий обмена между базами 1С
  • Компоненты обмена
  • Интеграция с БСП 2.2 (2.3)
  • Настройка компонент подсистемы «Обмен данными»
  • Настройка корректного обновления системы
  • Подготовка к переносу данных

Занятие 2. Простые переносы объектов

  • Перенос справочника с реквизитами примитивных типов
  • Настройка новой синхронизации данных
  • Настройка синхронизации данных в базе-приемнике
  • Перенос справочника с реквизитом ссылочного типа
  • Настройка правил конвертации предопределенных данных

Занятие 3. Простые переносы объектов. Написание обработчиков

  • Перенос групп справочника
  • Перенос документа с табличной частью
  • Конвертация Перечисление -> Справочник
  • Конвертация Справочник -> Перечисление

Занятие 4. Механизмы, лежащие в основе технологии: XML, XDTO, Универсальный формат

  • XML и XDTO
  • Перенос документов с помощью XDTO сериализации
  • Универсальный формат обмена данными
Читайте также:  Фильмы с 5 канальным звуком

Занятие 5. Конвертация объектов, отличающихся от объектов формата

  • Перенос реквизита, которого нет в объекте формата
  • Заполнение свойства Родитель
  • Перенос реквизитов, которых нет в объекте формата. Дополнительные реквизиты
  • Перенос Значений свойств контрагентов. Выгрузка
  • Перенос Значений свойств контрагентов. Создание ПКО и ПКС для загрузки
  • Перенос Значений свойств контрагентов. Формирование записей регистра ЗначениеСвойствОбъектов
  • Перенос Значений свойств контрагентов. Описание загрузки разных свойств
  • Загрузка обработчиков в КД

Занятие 6. Перенос объектов вместе с дополнительными данными

  • Перенос реквизита вместе с объектом свойства
  • Перенос данных по умолчанию. Подбор значения в Исходной базе
  • Перенос данных по умолчанию. Ручное формирование выгружаемого значения
  • Перенос данных по умолчанию. Загрузка

Занятие 7. Идентификация

  • Варианты идентификации, их плюсы и минусы
  • Настройка идентификации по полям поиска
  • Настройка двух наборов полей поиска
  • Загрузка данных по умолчанию с использованием ПКО
  • Загрузка данных по умолчанию без использования ПКО
  • Произвольный поиск объектов
  • Продолжение поиска, если объект не найден произвольным образом
  • Произвольный поиск объектов. Исправление возможных ошибок

Занятие 8. Параметры конвертации и алгоритмы

  • Алгоритмы
  • Регулирование отправки и получения
  • Сохранение списка выгруженных объектов
  • Заполнение параметра в пользовательском интерфейсе

Занятие 9. Произвольная выборка данных и задачи, ею решаемые

  • ПОД с произвольной выборкой данных
  • Перенос остатков ТМЦ. Настройка ПОД с произвольной выборкой
  • Создание обработки для выгрузки
  • Отладка выгрузки. Исправление возможных ошибок
  • Загрузка
  • Создание обработки
  • Перенос справочников

Занятие 10. Обработчики событий на стороне отправки

  • Механизм выгрузки зарегистрированных данных согласно ПОД
  • Обработчик ПОД При обработке: Отправка
  • Обработчик При обработке.Ветвление по ПКО
  • Обработчик При обработке. Ветвление по ПКО. Загрузка сообщения
  • Общий порядок событий, происходящих при выполнении ПКО на этапе отправки.Обработчик При отправке
  • Стек выгрузки, его устройство и применение
  • Удаление объектов

Занятие 11. Обработчики событий на стороне получения

  • Общий порядок событий при получении данных
  • Выполнение ПКО на этапе получения
  • Использование ПКО в ПОД на этапе получения
  • Реквизит плана обмена и пользовательская настройка при загрузке
  • Не замещать значение свойства
  • Отложенное заполнение объектов
  • Отложенная запись и отложенное проведение

Занятие 12. Регистрация объектов к выгрузке

  • Правила регистрации объектов
  • Обработчик ПРО Перед обработкой
  • Регистрация связанной информации
  • Общая схема выполнения ПРО
  • Переключатель режима
  • Начальная настройка отборов на узле
  • Обзор форм плана обмена

Занятие 13. Настройка обмена между типовыми конфигурациями

  • Загрузка правил в КД
  • Перенос остатков из БП 3.0 в ERP 2.1. Изменение выгруженных правил. Создание внешней обработки
  • Настройка обмена БП 3.0 -> ERP 2.1. Подключение новых правил
  • Перенос остатков из БП 3.0 в ERP 2.1 с помощью готовой обработки
  • Вариант настройки обмена
  • Конфликты

Примеры из курса

При обмене данными через Универсальный формат часто возникает проблема – для определенных реквизитов объекта нет аналогичных реквизитов формата.

Например, при переносе данных с разной структурой метаданных.

Есть несколько способов обойти эту проблему.

В данных видео рассмотрено использование для этих целей реквизита AdditionalInfo. Основной плюс этого подхода в том, что этот реквизит есть у всех тех объектов формата, которые являются потомками базового типа Object.

Перенос реквизитов с помощью AdditionalInfo – выгрузка данных

Перенос реквизитов с помощью AdditionalInfo – загрузка данных

Обмен через Универсальный формат построен на использовании планов обмена. Это означает, что выгружаются только те объекты, которые зарегистрированы на том узле плана обмена, по которому происходит обмен.

Если у этих объектов есть свойства ссылочных типов, то по умолчанию они не выгружаются целиком, как отдельные объекты. В узлах свойств выгружаются только их Ключевые свойства, необходимые, чтобы найти их в конечной базе.

В этом уроке мы покажем, как выгрузить объекты целиком, даже если они не были зарегистрированы на узлах плана обмена.

Перенос дерева объектов в Универсальном обмене данными – выгрузка данных

Перенос дерева объектов в Универсальном обмене данными – загрузка данных

Объем материалов курса

  • Видео – 21 учебный час
  • Методические материалы в PDF — 117 страниц А4
  • 16 практических заданий с решениями преподавателя

Формат курса, поддержка

Материалы доступны сразу после оплаты заказа – Вы скачиваете их с сайта и изучаете в любое удобное время.

Поддержка производится через Мастер-группу на сайте Курсы-по-1С.рф.

Полноценный доступ в Мастер-группу должен быть активирован не позднее 100 дней после покупки.

Актуальность курса

Материалы курса актуальны для версии БСП 2.3.2.73.

Если Вы планируете использовать более старшие версии БСП, то учтите, что изменились механизмы работы подсистемы БСП “Обмен данными”, также изменились интерфейсы.

Новый курс под последние версии БСП находится в процессе разработки и будет выпущен через несколько месяцев. Но для версий БСП 2.3.2.73 и младше будет актуален текущий курс.

Стоимость курса

Это значит, что если Вы начали заниматься по нашему курсу, но вдруг передумали (или, скажем, не имеете возможности), то у Вас есть 60-дневный срок для принятия решения – и если Вы производите возврат, мы возвращаем 100% оплаты.

Это возможно при оплате от физических лиц на сумму от 3 000 руб. до 150 000 руб.

Все, что Вам нужно сделать – это выбрать способ оплаты “Оплата через Яндекс.Касса”. Далее на сайте платежной системы выбираете “Заплатить по частям”, указываете срок и размер выплат, заполняете небольшую анкету – и через пару минут получаете решение.

От физических лиц – оплаты с карт, оплаты электронными деньгами (WebMoney, ЯндексДеньги), оплаты через интернет-банкинг, оплаты через салоны связи и так далее. Возможна также оплата заказа по частям (в рассрочку), в том числе без дополнительных процентов.

Начните оформлять заказ – и на втором шаге Вы сможете выбрать предпочтительный способ оплаты.

От организаций и ИП – безналичная оплата, предоставляются документы на поставку. Вы вводите заказ – и сразу можете распечатать счет на оплату.

Если компании требуется обучить нескольких сотрудников, мы обычно предлагаем “дополнительные комплекты”, которые стоят на 40% дешевле.

Для оформления заказа на “дополнительный комплект” выберите в форме 2 и более комплектов курса, начиная с второго комплекта стоимость курса будет на 40% дешевле.

Есть три условия использования дополнительных комплектов:

  • нельзя приобрести только дополнительный комплект, если до этого (или вместе с ним) не был приобретен хотя бы один обычный
  • на дополнительные комплекты не действуют еще какие-то скидки (они и так дисконтированны, получилась бы “скидка на скидку”)
  • на дополнительные комплекты не действуют акции (например, компенсация в 7000 рублей) по той же причине
Оцените статью
Добавить комментарий

Adblock
detector