Новый подход к обмену данными EnterpriseData
Интеграция - Файловый обмен (TXT, XML, DBF), FTP
Обмен данными через EnterpriseData - механизм сравнительно новый, появился около 4 лет назад. Тем не менее уже практически все обмены между типовыми конфигурациями используют именно его. Статьи на эту тему уже естественно есть, например вот очень хорошая статья Максима Сухова. Однако, на мой взгляд, требуется более расширенное описание как теоретической, так и практической части новой технологии и самого процесса. По этому, я хочу предложить Вашему вниманию цикл статей.
Остальные статьи из цикла:
EnterpriseData – часть 2. Процесс выгрузки данных
Часть 3. Процесс загрузки данных, Идентификация объектов
Сокращения, которые будут присутствовать в статье:
- ED – универсальный формат обмена (EnterpriseData)
- КД 2.0 – конвертация данных 2.x
- КД 3.0 – конвертация данных 3.0
Содержание
- Что такое универсальный формат?
- Преимущества обмена через универсальный формат
- Недостатки обмена через универсальный формат
- Обход выборки и подбор правил конвертации
- Конвертация объекта и всех его свойств
- XDTO сериализация данных и выгрузка в XML
Первая статья будет вводной, в основном теоретической. Ее задача - донести в общем, в чем заключается новая технология, фундамент, так сказать, без которого дальнейшее постижение будет затруднительно.
Сразу замечу, не все специалисты принимают обмен через ED «на ура». Существует довольно много скептиков, и их возражения весьма оправданы. В общем, ED вызывает много дискуссий между сторонниками и противниками. Я же постараюсь быть объективным, рассказать как есть, плюсы и минусы.
Одно можно сказать точно, нравиться нам это или нет, всем придется рано или поздно разбираться с новой технологией обмена, так как компания 1С явно дает понять, что будущее именно за ED.
Сейчас кто-то наверно набросится на меня, и скажет: «Да нет же, обмен с использованием правил КД 2.0 будет существовать и дальше!»
И… Будет прав.
Да, обмен по правилам КД 2.0 будет сосуществовать параллельно, для решения различных специфических задач, для поддержки обменов с конфигурациями предыдущих версий, и там, где применение обмена через ED не является рациональным по тем или иным причинам.
Ну что же, давайте перейдем, к сути вопроса. В чем же основные отличия обмена через ED от старого, проверенного годами, универсального обмена данными в формате XML, по правилам КД 2.0?
Фундаментальных отличия, на мой взгляд два:
- Обмен происходит не между двумя конфигурациями, как мы все привыкли, а между конфигурациями и универсальным форматом.
- Для реализации обмена данными применяется технология XDTO.
Что такое универсальный формат?
Говоря понятным языком, универсальный формат – это четко заданная структура данных, которые могут быть выгружены в файл обмена. Другими словами, это описание типов бизнес - объектов, которыми нам требуется обмениваться с другими системами. Описание формата разработано компанией 1С для реализации обменов между своими типовыми решениями, и выполнено оно в текстовом виде, а точнее, в виде XML схемы. В дереве конфигурации описание формата содержится в ветке «XDTO пакеты». XDTO пакеты, по своей сути и являются схемами XML, правда с некоторыми оговорками.
По скольку, бизнес не стоит на месте, описание универсального формата постоянно изменяется и дополняется компанией 1С. Соответственно, формат имеет версию, которая состоит из трех цифр. Первые две цифры являются значимыми и меняются при значительной реструктуризации описания формата. При их изменении, совместимости с предыдущими версиями не предусмотрено. Последняя цифра версии формата меняется в случае не значительных доработок: исправления ошибок или добавления свойств, использование которых не является обязательным. Такие изменения не приводят к потере совместимости с предыдущими версиями.
Пример наименования формата: EnterpriseData_1_6_2
1 и 6 – это значимые цифры версии формата.
Компания 1С в своих типовых продуктах гарантирует срок поддержки версии формата не менее 1 года с момента ее выхода. По факту этот срок обычно больше, но, все равно, эту особенность необходимо учитывать при реализации собственного механизма обмена данными. Сроки поддержки актуальных версий формата можно посмотреть по этой ссылке.
Вернемся к обмену данными. Как говорилось выше, обмен происходит между базами данных и ED:
Если быть точнее:
- При выгрузке происходит преобразование объектов базы-источника к типам, описанным в формате.
- При загрузке происходит обратная операция – преобразование данных в формате ED к типам объектов базы–приемника.
Сразу же можно выделить основные преимущества и недостатки нового подхода к обмену данными.
Преимущества обмена через универсальный формат
- Нам не требуется знать НИЧЕГО о структуре данных принимающий стороны для формирования файла с данными. В общем случае, это может быть даже не 1С, а любая другая система, поддерживающая структуру универсального формата.
- Корректировку алгоритма выгрузки или загрузки данных необходимо делать только в случае прекращения поддержки используемой версии формата у второго участника обмена.
- Не требуется включать правила конвертации объектов в файл с данными.
- Новый подход ведет к стандартизации бизнес – объектов, используемых для реализации учетной системы.
Недостатки обмена через универсальный формат
- Процесс обмена разбит на два не связанных друг с другом этапа: выгрузка данных и загрузка данных. Для каждого этапа необходимо создавать отдельные правила конвертации.
- Структура универсального формата накладывает ограничение на состав передаваемых данных. Это может вызывать большие трудности при попытке настроить передачу не стандартных данных. Наверно это самый значительный недостаток новой технологии.
- Конфигурация, участвующая в обмене данными должна иметь соответствующий функционал для поддержки механизмов обмена. Данный функционал предоставляется отдельной подсистемой БСП.
- Ограниченный срок поддержки версий формата.
И так, мы рассмотрели, что такое универсальный формат – сердце новой технологии обмена. Дальше, поговорим о средствах его реализации:
Примечание: В некоторых источниках я даже встречал названия обмена данными через универсальный формат – обмен XDTO.
Вообще, что такое XDTO и его реализация в 1С лучше всего описано в серии статей Андрея Овсянкина.
Как было написано выше, XDTO пакеты необходимы для хранения описания формата. Собственно, без их использования нельзя будет называть обмен - обменом через ED.
Не вдаваясь в подробности, «XDTO пакеты» это преобразованные схемы XML, они являются описанием типов бизнес – объектов, используемых при обмене данными. Преобразованные потому, что не все способы представления данных в XML могут быть представлены напрямую в XDTO.
Например, представление данных в виде текста между тегами «<Message>Текст сообщения</ Message>», нельзя представить в виде объектной модели XDTO, и она будет сымитирована. При загрузке в XDTO пакет будет добавлено дополнительное свойство, имитирующее текст сообщения. Подробнее об этом во второй статье Андрея Овсянкина тут.
Информация из пакетов XDTO используются объектами фабрики XDTO для типизации данных и их быстрого преобразования в XML и обратно.
Для XDTO пакета обязательно указывается пространство имен (принято использовать произвольный url адрес), которое является уникальным идентификатором каждого конкретного пакета. Пример описание XDTO пакета:
«Фабрика XDTO» – это объект платформы 1С. Также «Фабрика XDTO» - это глобальная переменная системы с типом «Фабрика XDTO», к которой можно обращаться для создания новых объектов фабрики. Объекты фабрики XDTO, это привычные нам объекты, обладающие свойствами, доступными через точку. Свойства эти описаны в пакете XDTO, на основании которого каждый такой объект создан.
Однако, важно понимать, что объекты фабрики XDTO не имеют абсолютно ни какой связи с объектами ИБ, не смотря на внешнюю схожесть. Фабрика XDTO имеет представление только об XML типах, описанных в пакетах XDTO.
Пример:
ТипОбъектаТовар = ФабрикаXDTO.Тип(“http://my_url_adres/”, “Товар”);
Товар = ФабрикаXDTO.Создать(ТипОбъектаТовар );
«http://my_url_adres/» - это пространство имен XDTO пакета, в котором существует описание для объекта «Товар». Далее, можно заполнять свойства объекта «Товар», как обычного объекта системы.
Удобством использования фабрики XDTO является то, что ее объекты очень легко преобразуются в XML для последующей выгрузки в файл обмена.
Пример:
XMLДокумент = Новый ЗаписьXML;
ФабрикаXDTO.Записать(XMLДокумент , Товар);
Примечание: Механизмы, реализованные в БСП не требуют от разработчика непосредственной работы с объектами фабрики XDTO. Но, для понимания общей картины происходящего, я думаю, будет не лишним иметь об этом представление.
Ну что же, давайте рассмотрим основной функционал БСП, реализующий механизмы обмена данными.
Компоненты, предоставляемые БСП
Под термином «компоненты», я подразумеваю набор объектов, которые необходимы для реализации механизмов обмена данными через ED. Строго говоря, можно выполнять обмен данными и не используя их. Но тогда, все процедуры по преобразованию данных, выполнению обработчиков, работе с фабрикой XDTO, регистрации объектов к выгрузке - придется реализовывать самостоятельно.
Подсистема БСП предлагает следующие объекты для реализации механизмов обмена:
- План обмена – необходим для формирования списка объектов к выгрузке. Принципиальным отличием от обмена по правилам КД 2.0 является то, что при обмене через ED нет необходимости создавать отдельный план обмена для каждого типа конфигураций – корреспондентов. Планов обмена необходимо ровно столько, сколько используется различных версий формата. Также, в модуле менеджера плана обмена указываются некоторые необходимые настройки: версия формата, ограничения для выгрузки данных, значения «по умолчанию».
- Обработка «Конвертация объектов XDTO» - точка входя. Обработка, с помощью которой выполняются настройки обменов, выгружаются и загружаются данные.
- Общий модуль «ОбменДаннымиXDTOСервер» - модуль, в котором реализованы основные процессы выгрузки и загрузки данным.
- Общий модуль «ОбменДаннымиПредопределяемый» - модуль, в котором можно переопределить стандартное поведение системы. Например, добавить дополнительный план обмена или переопределить менеджер обмена данными.
- Общий модуль «ОбменДаннымиСобытия» - модуль, в котором реализованы алгоритмы регистрации объектов к выгрузке.
- Подписки на события – регистрация объектов к выгрузке при их добавлении, изменении, удалении.
- Общие команды – команды для выполнения настройки обменов данными и их непосредственного выполнения.
Так же как и в старой технологии, в новой необходимы правила конвертации. Только, правила теперь находятся в общем модуля каждой конфигурации, которая участвует в процессе обмена. Общий модуль имеет стандартное наименование «МенеджерОбменаЧерезУниверсальныйФормат». Название, в принципе, может быть любым.
Хранение правил внутри конфигурации имеет как преимущества, так и недостатки. Например, достаточно удобно выполнять отладку механизмов выгрузки и загрузки. Также, не значительные доработки можно выполнить непосредственно, корректировкой модуля менеджера обмена, без использования КД 3.0. Пример такой доработки можно посмотреть в отдельной статье.
Недостатком такого подхода можно считать необходимость обновлять конфигурацию базы данных каждый раз, когда требуется выполнить модификацию правил конвертации. Существует, правда, возможность использования правил из модуля внешней обработки, но тогда будут потеряны и преимущества.
Для создания и корректировки правил конвертации применяется отдельная конфигурация – КД 3.0. В данной конфигурации можно настроить соответствия между объектами информационных баз и объектами используемой версии формата. Также, можно написать программный код для обработки ряда событий. Например, можно переопределить или указать дополнительные данные перед их преобразованием в XDTO объекты в процессе выгрузки. Выполнить какие-либо действия с данными перед их записью в объекты ИБ в процессе загрузки. Более подробно все основные события выгрузки и загрузки данных, будут рассмотрены в следующих статьях.
Рассмотрим, каким образом происходит выгрузка данных.
Обход выборки и подбор правил конвертации объектов
В первую очередь анализируется состав объектов плана обмена. Все зарегистрированные к выгрузке объекты помещаются в выборку и поочередно обходятся.
Для каждого найденного объекта подбираются и начинают выполняться правила обработки данных, которые определены в общем модуле «МенеджерОбменаЧерезУниверсальныйФормат». Основное назначение правил обработки данных – это подбор правила конвертации для каждого объекта. В общем случае, правил конвертации может быть несколько для одного типа объектов.
Конвертация объекта и всех его свойств в набор вложенных структур
Выполняются выбранные правила конвертации объекта, которые состоят из правил конвертации отдельных свойств объекта и его предопределенных данных. На этом этапе формируется структура данных. Как было описано выше, есть возможность вмешаться в этот процесс и выполнить дополнительные действия с данными. Итогом процесса конвертации являются подготовленные структуры с описанием передаваемых данных. Это еще не объекты фабрики XDTO, это просто вложенные друг в друга структуры, с конечными данными простых типов (число, строка, дата).
Сериализация данных и выгрузка в XML
На самом деле, существует два вида сериализации: сериализация XDTO и сериализация XML. Первый механизм преобразует объекты информационной базы в объекты XDTO. Второй преобразует объекты XDTO в XML.
В нашем случае, данные уже преобразованы в набор вложенных структур со значениями простых типов. Тем не менее, сериализация XDTO все равно необходима, так как фабрика XDTO имеет представление исключительно только об XML – типах.
На данном этапе происходит создание объектов фабрики XDTO. На основании данных подготовленных структур происходит заполнение этих объектов. Выполняется приведение типов в соответствие с описанием в XDTO пакете формата. Также, выполняется проверка соответствия подготовленных структур и описания формата: проверка типов, наличие всех обязательных свойств и прочее. В случае выявления ошибок, выполнение выгрузки данных прерывается.
Если все данные успешно перенесены в объекты фабрики XDTO, выполняется преобразование данных в XML и выгрузка в файл обмена.
На этом общее описание процесса выгрузки можно завершить. Более детально оно рассмотрено в этой статье.
Процесс загрузки данных, в общем, аналогичен процессу выгрузки, только все происходит в обратном порядке:
- Выполняется чтение данных из файла обмена
- Выполняется создание объектов фабрики XDTO на основании данных XML и типов в описании формата.
- Каждый объект преобразуются в набор вложенных структур, для удобного доступа к свойствам из обработчиков.
- Выполняется поиск правила обработки данных и его выполнение.
- Обходятся все доступные для объекта правила конвертации.
- Происходит конвертация объекта и его свойств из набора вложенных структур в данные ИБ. На данном этапе можно получить какие-либо дополнительные данные из преобразованного объекта XDTO и записать их в дополнительные свойства формируемого объекта ИБ, для последующей обработки.
- Происходит поиск загруженного объекта в ИБ – приёмнике. По умолчанию поиск происходит по внутреннему уникальному идентификатору. Это поведение можно изменить, я расскажу об этом более подробно в следующих статьях.
- Выполняются дополнительные действия с перед записью найденного или нового объекта.
- Выполняются дополнительные действия после загрузки всех данных.
Наверно, на этом я закончу вводную статью, так как, она и так получилась достаточно объемной, неожиданно для меня. Надеюсь, что общее представление о новом формате обмена данными у Вас сформировалось, в следующих статьях я планирую более детальное рассмотрение отдельных аспектов. Обязательно буду приводить примеры.
Ставьте плюсик, если моё начинание кажется Вам полезным J.
В следующих статьях я планирую более подробно рассмотреть следующие темы:
- Процесс выгрузки данных, обработчики выгрузки.
- Процесс загрузки данных, поиск объектов в ИБ, обработчики загрузки.
- Структура XDTO пакета – как его читать, дополнять, загружать и выгружать.
- Импорт подсистем БСП для реализации обмена данными в собственных ИБ
- Работа с КД 3.0
Другие мои статьи из серии «Новый подход к обмену данными»
Вступайте в нашу телеграмм-группу Инфостарт
Обмен данными через универсальный формат обмен XDTO EnterpriseData ED
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Разработчик 1С:Предприятие 8 1С:Комплексная автоматизация 1.х 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)
Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена | Можно выполнить переход с УПП на БП 3 или запускать выгрузку данных за выбранный период времени | Переносятся документы, начальные остатки и вся справочная информация | Есть фильтр по организации и множество других параметров выгрузки | Поддерживается несколько сценариев работы: как первичный полный перенос, так и перенос только новых документов | Перенос данных возможен в "1С: Бухгалтерия 3.0" версии ПРОФ, КОРП или базовую | Переход с "1С: УПП1.3" / "1С:КА 1.1" на "1С:БП3.0" с помощью правил конвертации будет максимально комфортным! | Можно бесплатно проверить перенос на вашем сервере!
50050 руб.
25.02.2015 192519 383 296
SALE! 10%
Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Разработчик 1С:Предприятие 8 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)
Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен и синхронизацию в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.
27633 руб.
12.06.2017 164992 1009 329
Перенос данных 1C Взаиморасчеты Оптовая торговля Логистика, склад и ТМЦ Файловый обмен (TXT, XML, DBF), FTP Системный администратор Разработчик 1С:Предприятие 8 1С:Управление торговлей 10 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Управленческий учет Платные (руб)
Можно проверить до покупки, оставьте заявку! Воспользовались более 268 компаний! Перенос данных из УТ 10.3 в УТ 11 | из УТ 10.3 в КА 2 | из УТ 10.3 в ERP. Решение для перехода с УТ 10.3. Можно перенести начальные остатки, нормативно-справочную информацию и все возможные документы. При выгрузке можно установить отбор по периоду, организациям и складам.
50200 руб.
24.04.2015 211428 186 254
Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Разработчик 1С:Предприятие 8 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 Бухгалтерский учет Управленческий учет Платные (руб)
Переносите справочную информацию, остатки и документы из УПП 1.3 в ERP 2.6 и КА 2.6 с помощью готовых правил. Переносится более 60 видов документов. Простой интерфейс и понятные настройки.
42000 руб.
24.06.2020 73113 108 35
Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Разработчик 1С:Предприятие 8 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)
Переносите справочную информацию, остатки и документы из УПП 1.3 в Бухгалтерию 3.0 с помощью готовых правил. Переносится более 50 видов документов. Простой интерфейс и понятные настройки.
42000 руб.
15.12.2021 37103 268 68
Операции по ВЭД Файловый обмен (TXT, XML, DBF), FTP Разработчик Бухгалтер 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 Россия Бухгалтерский учет Платные (руб)
Федеральная таможенная служба России давно поддерживает унифицированный формат электронных документов для обмена с информационными системами предприятий. xmlns="urn:customs.ru:Information:ExchangeDocuments:". Структура, утвержденная комиссией Таможенного союза. Осталось только сделать загрузку в 1С из этого формата. На выходе - два документа ГТД по импорту и Поступление (акты, накладные) Обработка актуализирована на начало 2026 года (ставка НДС 22%)
24400 руб.
09.08.2016 97829 380 379
Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Разработчик 1С:Предприятие 8 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Управление производственным предприятием Россия Платные (руб)
Регулярный обмен, выгрузка, перенос из КА 1.1, УПП 1.3, УТ 10.3 для обмена с любыми конфигурациями, поддерживающими обмен в формате EnterpriseData (КД3) - БП 3.0, ERP, КА 2, УТ 11, Розница 3, УНФ 3 и другими. Правила для старых и доработанных конфигураций не требуют синхронного обновления и совместимы с новыми и будущими конфигурациями. Обмен по расписанию, через папку, FTP, почту.
27572 руб.
18.02.2016 209222 686 559
Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Разработчик 1С:Предприятие 8 1С:Комплексная автоматизация 1.х 1С:Управление производственным предприятием 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)
Правила переноса кадровых и расчетных данных и справочной информации из "1С:УПП1.3" или "1С:КА 1.1" в "1С:ЗУП 3.1 | Разработан в формате КД 2 (правила конвертации данных) | При выгрузке есть фильтр по организациям | Обновляется при выходе новых релизов 1С | Развитие алгоритмов | Расчетные документы переносятся в документ "Перенос данных" | Создаются документы "Начальная штатная расстановка" и "Начальная задолженность по зарплате", переносятся кадровые документы
58000 руб.
29.10.2018 64458 86 137
Печально, что в типовых правилах это не работает и недостаточно объектов формата, например для переноса наборов доп реквизитов и сведений.
И большой минус в функционале расширений - нельзя расширить состав плана обмена, нельзя подменить XDTO пакет. Если этот вопрос решить в будущих версиях, расширением можно будет решить все вопросы обмена.
А) внести изменения в пакет XDTO
Б) внести измнения в ПКО в КД3.0
В) перенести код модуля обработно в конфигурацию
В своем обмене на v8msg просто вносишь изменения в код модуля загрузки и все. Выгрузка делается системой автоматически со всеми реквизитами объекта. Править ничего не надо
+ очень важно. Для обмена, основанного на ФабрикахXDTO, имеет значение порядок тэгов в файле XML! В своем обмене порядок в XML файле может быть произвольный
вы забыли помножить количество действий на n-обменов. в примере выше получится минимум 5 действий, а в КД 3.0 так и останется 3. еще раз я не утверждаю что КД 2.0 плох, а 3.0 - идеален. вы же должны знать на, что способен тот или иной инструмент и что из этого следует. всё равно что сравнить пилу и бензопилу :)
насчет порядка - всё наоборот. в КД 2.0 он был важен, в 3.0 - нет
Например УПП уже давно кардинально не меняется. Сделал один раз правила в КД3 и всё. Вне зависимости от появления новых документов в ERP, БП или УТ, правила в УПП не нужно дорабатывать.
(12)
То же самое могу сказать про КД 3.0. В правила добавил универсальную процедуру, которая умеет выгружать все реквизиты объекта, в том числе и ссылочные, на другой стороне аналогичная процедура собирает данные и заполняет реквизиты. Если в конфигурацию добавили реквизит, правила не нужно дорабатывать, он подхватится автоматически.
Для выгрузки ссылочного объекта, который не поддерживается форматом ED тоже нашлось решение, не требующее менять пакет XDTO.
Никогда не задумывался о порядке тегов при использовании КД 3.0, если пользоваться БСП.
Для вводной статьи по ED пугать людей обязательностью доработки XDTO не стоит. ;) Это не обязательная процедура, а возможность.
Сложность - понятие относительное. Специалист должен уметь всё. Применять технологии к месту, а не что-то одно, что он умеет. Для типовых конфигураций в настоящее время стандарт - универсальный формат.
На счёт сложности. На EnterpriseData есть, написанное мной, рабочее решение: экспорт/импорт справочников и документов в стороннюю ERP систему. Примерный поток несколько тысяч объектов в день и обмен v8msg. Второй вариант мне показался предпочтительнее
Но как в статье отмечено, 1С продвигает ED. И рано или поздно типовой функционал будет работать в основных вариантах обменов и для большинства конечных пользователей этого будет достаточно. Мелкие недочеты исправят программисты.
Полностью менять типовой обмен на свой очень хороший будут единицы.
Меньше всего требуют доработок правила для БП 3.0. Видимо на обмен с БП 3.0 все типовые правила на КД3 заточены.
Самые нерабочие, по моему - правила ED для УНФ.
Требуют доработок все ERP КА УТ, розница, если настраивать обмен между собой и используются виды номенклатуры, доп реквизиты, характеристики..
EDT аналогично - баги уберут, инструменты появятся, удобство повысится.
Возможность копаться на низшем уровне и переставлять биты информации останется, но такой ручной труд "сделать всё самому" не сможет составить конкуренцию готовым решениям.
Например, можно написать своё решение управления данными на MS Assess 2000-х годов, создать таблицы, связи, индексы, написать функционал взаимодействия с пользователем, программировать каждое действие. Или перейти на 1С и написать тоже самое. Мне приходилось этим заниматься, специально сравнивал затраты времени, чтобы обосновать переход на 1С 8.0. Разница оказалась в 8 раз в пользу 1С.
С каждым годом объёмы информации и сложность обработки будут расти, чтобы не утонуть, придётся использовать комбайны типа EDT, стандартизировать обмены как в ED и т.п.
До появления ED синхронизация с 1С осуществлялась напрямую через com, прямыми запросами к СУБД и т.п.
Других универсальных технологичных способов обмена с типовыми базами 1С, которые поддерживаются типовыми базами пока нет. Если появится, можно будет обсуждать.
Расширения же тоже можно использовать по разному. Вариант один - точечно править процедуры с использованием &Вместо - подобный вариант отличный в плане контроля действа, но неудобен в разработке и поддержке. Вариант два - подменять в расширении общий модуль
&Вместо("ДоступныеВерсииУниверсальногоФормата")
Процедура Наш_ДоступныеВерсииУниверсальногоФормата(ВерсииФормата)
ВерсииФормата.Вставить("1.2", МенеджерОбменаЧерезУниверсальныйФормат);
ВерсииФормата.Вставить("1.3", Наш_МенеджерОбменаЧерезУниверсальныйФормат);
ВерсииФормата.Вставить("1.4", Наш_МенеджерОбменаЧерезУниверсальныйФормат);
ВерсииФормата.Вставить("1.5", Наш_МенеджерОбменаЧерезУниверсальныйФормат);
ВерсииФормата.Вставить("1.6", Наш_МенеджерОбменаЧерезУниверсальныйФормат);
КонецПроцедуры ПоказатьАвтору респект.
Из-за ограниченного описания видов документов и справочников в ED можно поступить 2-мя способами.
1. Выбрать справочник и документ формата для переноса любого справочника и документа.Например, СтатьиДДС и КорректировкаДолга.
Написать процедуры, которые упаковывают все реквизиты и табличные части в данные формата и распаковывают их обратно.
В правилах перед началом конвертации процедура проверяет наличие ПКО и самостоятельно заполняет для ПОД используемые ПКО, чтобы не заморачиваться ручным написанием кода для ПОД загрузки.
2. Заняться доработкой формата ED Например сделать формат 1.61 - за основу берем 1.6 и дорабатываем. Новый формат вставляем в расширение, модуль с новыми правилами туда же. Подобные расширения с идентичным форматом нужно вставить во все базы, участвующие в обмене.
Ещё не забыть загрузить в КД3 конфигурацию с регистрами накопления и расчета.
1-й вариант у меня получился. Написал обработку, создание правил для нового документа или справочника занимает меньше секунды ;)
2.- вариант очень затратный по объёмам. Правильно продумать состав документов и справочников. В процессе доработки и отладки нужно часто менять формат, соответственно одновременно обновлять все базы, участвующие в обмене.
По трудозатратам сложно сказать про этот вариант, т.к. всё делалось в течение нескольких лет ;) Используется множество процедур. От выгрузки одного реквизита по имени эволюционировало в выгрузку документа со всеми реквизитами и табличными частями.
Недостаток первого варианта - конфигурации должны быть примерно идентичными. Если они отливаются обмен не поломается, просто данные по отличающимся реквизитам никуда не запишутся.
Плюс 2-го варианта - это правильное использование универсального формата обмена, обмен возможен между сильно отличающимися конфигурациями.
Если начинать с нуля, может быть и 2-й вариант будет быстрее. Когда начинал с 1-м вариантом, расширение не поддерживало XDTO пакеты.
Минус 2-го варианта в недостатках конфигурации КД3 - там нет как в КД2 автоматического заполнения ПКС. Всё руками. Это тоже пришлось автоматизировать.
Я то думал что для всех документов будет соответствие с ED , а тут такой облом , а так надо разбираться как все сворачивать в другой формат и как разворачивать потом , боюсь застрять на середине. Если как говорит , Максим у него на доработки КД 3.0 ушло несколько лет , то я за полмесяца явно не разберусь.
И спустя еще несколько лет мы получим ситуацию как с правами доступа (вместо набора прав - кирпичики, объединяемые в профиль, сохраняемый в пользовательском режиме).
Разбиваем EnterpriseData на подсистемы или даже отдельные объекты, для каждого пишем отдельный собственный формат. Унификация сохранится, в случае несинхронного обновления корреспондентов (как у нас часто бывает) можно будет отключить нерабочие участки в режиме предприятия.
Ещё возникала аналогичная мысль - основной обмен через ED, вспомогательный на другом плане обмена с использованием правил на КД2.
(58)
Задержка может возникнуть с КД3 если нет опыта. И для обмена ЗУП 3 - ЗУП 3 нужно создать правила для примерно 60 документов не считая справочников. Умножаем на 3 (2 ПКО и 1 ПОД), получаем гору ручного труда.
Для этого можно использовать реквизит узла "ПутьКМенеджеруОбмена" и совсем немного доработать процедуру "ДоступныеВерсииФорматаОбмена" из модуля менеджера плана обмена.
Но фактически такой вариант будет означать встраивание конвертации 3 в конфигурацию (модуль на плане обмена вместо обработчиков до и после начала обмена, модуль на часть XDTO вместо обработчиков перед началом выгрузки, после загрузки).
В конвертации данных 2 я пока тоже только осваиваюсь, не понимаю, как отключить регистрацию чего-то в штатных в правилах регистрации объектов.
Для обмена данными через формат EnterpriseData у конфигураций, использующих "Библиотеку стандартных подсистем", есть два веб-сервиса:
EnterpriseDataUpload – упрощенный вариант для загрузки данных в информационную базу из сторонних приложений. Не требует специальных настроек на стороне конфигурации (кроме развертывания собственно веб-сервиса); однонаправленный обмен данными – ТОЛЬКО импорт данных в информационную базу.
EnterpriseDataExchange – для двустороннего обмена данными между конфигурацией и сторонним приложением. Для работы с ним необходима настройка обмена данными на стороне конфигурации.
С одной стороны это недостаток - общий модуль правил на все узлы, с другой стороны если всем дать функционал на каждый узел свои правила, то после обновления конфигурации пользователи массово забудут обновить правила и так же будут ругать новый формат обмена.
Поэтому если программист, обслуживающий обмен смог настроить для каждого узла свои правила, то он и сможет его поддерживать в рабочем состоянии.
Т.е. так, как сделано сейчас в типовых наверное логично.
ИМХО, конфигурации уровня КА2 и ЕРП должны иметь возможность настроек. А к примеру в БП или УНФ это будет только мешать. Но подход один.
Все типовые обмены в целом нормально работают. Основное назначение - обмен между разнородными базами.
В ERP и КА последних версий появились настройки для каждого узла обмена - отбор по разделам учета.
Проблемы возникают при попытке через ED обменяться однотипными базами. КА 2 - КА 2, ЗУП - ЗУП. Для КД2 наоборот - создать правила для обмена однотипными базами легко.
Последние версии ED обмениваются информацией какие виды объектов они умеют отправлять и принимать. Для универсального обмена это полезно. Не нужно отправлять лишнее.
Про правила регистрации тоже хотел бы почитать.
В КД редакции 3.1 появились новые возможности, а также получили дальнейшее развитие существующие. Ниже приводится описание основных изменений в новой редакции.
Разработка правил регистрации
Новая версия конфигурации позволяет создавать правила регистрации объектов по аналогии с правилами регистрации в конфигурации КД 2.1. Но, в отличие от версии 2.1, правила регистрации могут быть выгружены как в формате XML, так и обычным кодом.
Разработка правил конвертации в формате XML
Добавлена возможность разрабатывать не только обмен между конфигурацией и форматом EnterpriseData, но и правила конвертации в формате XML – таким образом, можно будет использовать единый инструмент для разработки тех и других правил конвертации.
Добавлены проверки правил конвертации, включающие в себя проверку на использование в правилах конвертации удаленных реквизитов конфигурации.
Автоматическая загрузка описания конфигурации
Добавлена возможность автоматически загружать описание конфигурации из каталога, в который ранее были выгружена конфигурация в виде XML-файлов, либо указав путь к хранилищу конфигурации, либо из каталога, в котором хранится исходный код конфигурации в формате 1C:Enterprise Development Tools (EDT). Также есть возможность задать расписание для обновления описания метаданных.
Автоматическая выгрузка подготовленных правил конвертации
В редакции 3.1 добавлена возможность автоматической выгрузки готовых правил конвертации или регистрации в каталог, в котором хранится исходный код конфигурации в формате EDT либо расположены исходные коды конфигурации в формате XML, выгруженные из конфигуратора.
Автоматическое создание правил конвертации
Добавлена возможность автоматического создания правил конвертации между двумя схожими конфигурациями. Сопоставление метаданных происходит по их внутреннему идентификатору. Следует отметить, что внутренние идентификаторы загружаются и хранятся в описании конфигурации только в том случае, если загрузка описания была произведена из каталога, в котором хранится исходный код конфигурации в формате EDT либо в XML-файлах, выгруженных из конфигуратора.
Совместная работа
КД 3.1 позволяет вести разработку правил нескольким разработчикам одновременно. Для этого реализованы функции захвата объекта, помещения объекта в основную конвертацию, возможность выгрузки конвертации как с учетом изменения захваченных для редактирования объектов, так и без учета изменения этих объектов. Также используется механизм версионирования объектов.
Работа с механизмом расширения формата EnterpriseData
КД 3.1 позволяет разрабатывать новые версии формата EnterpriseData, а также расширять существующие. Создавать новые версии формата можно теперь непосредственно в конфигурации КД. Также существует возможность делать расширения существующей версии формата и его объектов, добавляя значения перечислений, реквизиты ключевых свойств, реквизиты табличных частей и т. д.
Ну или у них какая-нибудь хитрая вообще бизнес-модель или вообще там какая-то модель существования - что надо все чтобы было через ж:)))))
Просто очень обидно, что вроде как основа-то есть - очень хорошая, заложенная еще с 7-ки, а вот реализация - гораздо хуже, чем могла бы быть.
Задумка хорошая, но как это расширение формата использовать в синхронизации через планы обмена?
В доработанном мной формате есть сущности Документ.УниверсальныйДокумент, Справочник.УниверсальныйСправочник и Справочник.УниверсальныйСправочникГруппа, а так же универсальные процедуры для выгрузки всех реквизитов через "AdditionalInfo", их даже в правилах описывать не нужно - выгружается всё, что есть типовое и нетиповое.
Не понятно - почему вот не собраться и не обсудить им там - как бы вот например и что можно было сделать лучше - реализовать эту идею с универсальным обменом - СРАЗУ, с самого начала. А не так вот - о, идея хорошая, запускаем - и потом и через годы там не всегда появляется нормальная реализация, прям такая хорошая. В принципе на 8-ку многие люди не решались переходить и через 5 лет после ее появления - говоря, что она сырая, хотя возможностей там уже было больше. Ну ладно, это я уже далеко отошел от темы вопроса:))) Спасибо Вам - на самом деле прояснили многое -я как раз хотел понять - в чем разница между простым обменом, который есть например в ЗУП при настройке синхронизации и ED, теперь знаю, спасибо:) и думаю многие Вам тоже спасибо скажут (жалко что не сами 1С:)) - за то, что вот продвигаете -поясняете про ED
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 963164
Создание 14.12.18 10:06
Обновление 16.09.19 21:27
Просмотры 98814
Загрузки 0
Рейтинг
321
Комментарии 85
Код открыт Да
Рубрики Файловый обмен (TXT, XML, DBF), FTP
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
