Новый подход к обмену данными EnterpriseData

16.09.19

Интеграция - Файловый обмен (TXT, XML, DBF), FTP

Хочу предложить Вашему вниманию цикл статей, посвященных обмену данными через универсальный формат (EnterpriseData или ED).

Обмен данными через EnterpriseData - механизм сравнительно новый, появился около 4 лет назад. Тем не менее уже практически все обмены между типовыми конфигурациями используют именно его. Статьи на эту тему уже естественно есть, например вот очень хорошая статья Максима Сухова. Однако, на мой взгляд, требуется более расширенное описание как теоретической, так и практической части новой технологии и самого процесса. По этому, я хочу предложить Вашему вниманию цикл статей.

Остальные статьи из цикла:

EnterpriseData – часть 2. Процесс выгрузки данных

Часть 3. Процесс загрузки данных, Идентификация объектов

Сокращения, которые будут присутствовать в статье:

ED – универсальный формат обмена (EnterpriseData)
КД 2.0 – конвертация данных 2.x
КД 3.0 – конвертация данных 3.0

Содержание

Введение
Новый формат обмена данными

Что такое универсальный формат?
Преимущества обмена через универсальный формат
Недостатки обмена через универсальный формат

Технология XTDO

XDTO пакеты
Фабрика XDTO

Компоненты, предоставляемые БСП
Правила конвертации данными
Процесс выгрузки данных

Обход выборки и подбор правил конвертации
Конвертация объекта и всех его свойств
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С, а любая другая система, поддерживающая структуру универсального формата.
Корректировку алгоритма выгрузки или загрузки данных необходимо делать только в случае прекращения поддержки используемой версии формата у второго участника обмена.
Не требуется включать правила конвертации объектов в файл с данными.
Новый подход ведет к стандартизации бизнес – объектов, используемых для реализации учетной системы.

Недостатки обмена через универсальный формат

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

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

Реализация обмена данными через ED

Технология XTDO

Примечание: В некоторых источниках я даже встречал названия обмена данными через универсальный формат – обмен XDTO.

Вообще, что такое XDTO и его реализация в 1С лучше всего описано в серии статей Андрея Овсянкина.

XDTO пакеты

Как было написано выше, XDTO пакеты необходимы для хранения описания формата. Собственно, без их использования нельзя будет называть обмен - обменом через ED.

Не вдаваясь в подробности, «XDTO пакеты» это преобразованные схемы XML, они являются описанием типов бизнес – объектов, используемых при обмене данными. Преобразованные потому, что не все способы представления данных в XML могут быть представлены напрямую в XDTO.

Например, представление данных в виде текста между тегами «<Message>Текст сообщения</ Message>», нельзя представить в виде объектной модели XDTO, и она будет сымитирована. При загрузке в XDTO пакет будет добавлено дополнительное свойство, имитирующее текст сообщения. Подробнее об этом во второй статье Андрея Овсянкина тут.

Информация из пакетов XDTO используются объектами фабрики XDTO для типизации данных и их быстрого преобразования в XML и обратно.

Для XDTO пакета обязательно указывается пространство имен (принято использовать произвольный url адрес), которое является уникальным идентификатором каждого конкретного пакета. Пример описание XDTO пакета:

Описание универсального формата

Фабрика 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

Другие мои статьи из серии «Новый подход к обмену данными»

Пример доработки правил конвертации данных без использования КД 3.0

Обмен данными через универсальный формат обмен XDTO EnterpriseData ED

+308 –

См. также

SALE! 20%

Синхронизация и обмен для ERP 2.5, КА 2.5, УТ 11.5 БП 3.0, Розница, УНФ и других с EnterpriseData (универсальный формат обмена), правила обмена

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 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. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

~~26280~~ 22338 руб.

12.06.2017 141467 798 297

419

SALE! 10%

Перенос данных из УПП 1.3 в БП 3.0. Переносятся документы (обороты за период), справочная информация и остатки

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.234.x) и БП 3.0 (3.0.161.x). Правила подходят для версии ПРОФ и КОРП.

~~35000~~ 31500 руб.

15.12.2021 23985 169 51

127

SALE! 10%

Перенос данных из УТ 10.3 в УТ 11.5. Переносятся документы (обороты за период), справочная информация и остатки

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 10 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УТ 10.3 (10.3.88.x) и УТ 11.5 (11.5.19.x).

~~35000~~ 31500 руб.

23.07.2020 51189 228 69

185

SALE! 10%

Перенос данных из ERP 2 / КА 2 в ЗУП 3. Переносятся остатки, документы и справочники

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из ERP в ЗУП 3 | из КА 2 в ЗУП | Готовые правила конвертации данных (КД 2) для переноса остатков, документов с движениями и справочной информации 3 | Есть перенос начальной задолженности по зарплате и начальной штатной расстановки на выбранную дату | Обороты за прошлые годы (данные для расчета среднего) переносятся свернуто в документ "Перенос данных" | Есть фильтр по организациям | Документы за текущий период переносятся сразу с движениями, поэтому не потребуется делать перерасчеты | Перенос можно проверить перед покупкой, обращайтесь!

~~53111~~ 47800 руб.

03.12.2020 36568 94 66

SALE! 10%

Перенос данных из УПП 1.3 / КА 1.1 в БП 3. Переносятся документы, справочники и начальные остатки

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 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" с помощью правил конвертации будет максимально комфортным! | Можно бесплатно проверить перенос на вашем сервере!

~~48278~~ 43450 руб.

25.02.2015 171155 303 257

378

SALE! 15%

Обмен УПП 1.3, КА 1.1, УТ 10.3 с EnterpriseData (универсальный формат обмена) ED2

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 Платформа 1C v8.2 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Управление производственным предприятием Россия Платные (руб)

Регулярный обмен, выгрузка, перенос из КА 1.1, УПП 1.3, УТ 10.3 для обмена с любыми конфигурациями, поддерживающими обмен в формате EnterpriseData (КД3) - БП 3.0, ERP, КА 2, УТ 11, Розница 2, УНФ 1.6 и другими. Правила для старых и доработанных конфигураций не требуют синхронного обновления и совместимы с новыми и будущими конфигурациями. Обмен по расписанию, через папку, FTP, почту.

~~15300~~ 13005 руб.

18.02.2016 186855 589 509

526

SALE! 10%

Перенос данных и обмен из УТ 10.3 в УТ 11 / КА 2 / ERP 2. Переносятся документы, справочники и остатки

Перенос данных 1C Взаиморасчеты Оптовая торговля Логистика, склад и ТМЦ Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Управление торговлей 10 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Управленческий учет Платные (руб)

Можно проверить до покупки, оставьте заявку! Воспользовались более 268 компаний! Перенос данных из УТ 10.3 в УТ 11 | из УТ 10.3 в КА 2 | из УТ 10.3 в ERP. Предлагаем качественное и проверенное временем решение для перехода с УТ 10.3. Можно перенести начальные остатки, нормативно-справочную информацию и все возможные документы. При выгрузке можно установить отбор по периоду, организациям и складам. При выходе новых релизов конфигураций 1C оперативно выпускаем обновление переноса данных.

~~55778~~ 50200 руб.

24.04.2015 194950 150 243

280

SALE! 10%

Перенос данных из ERP 2/ КА 2 / УТ 11 в УПП 1.3 / КА 1.1 / УТ 10.3. Переносятся все возможные документы и справочники

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

~~53111~~ 47800 руб.

28.11.2015 83235 32 125

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. genayo 14.12.18 10:08 Сейчас в теме

Поправьте заголовок, ну не серьёзно же...

Ответить

3. genayo 14.12.18 10:28 Сейчас в теме

(1) Э... Не намного лучше стало...

18. ids79 8535 14.12.18 16:29 Сейчас в теме

(1)Исправил

2. Fox-trot 163 14.12.18 10:14 Сейчас в теме

так там и картинки надо тогда менять

4. MuI_I_Ika 1121 14.12.18 10:52 Сейчас в теме

Да, новый формат корпоративной даты это сильно.

6. kembrik 10 14.12.18 11:48 Сейчас в теме

(4) ВходнойПрайс тоже норм)

5. nyam-nyam 14.12.18 11:16 Сейчас в теме

Уважаемый автор!
Буду весьма признателен за исправление во всём тексте и картинках/слайдах всяких разных вариаций на тему написания ED на единственно верный вариант - EnterpriseData.

19. ids79 8535 14.12.18 16:30 Сейчас в теме

(5)Исправил

39. MaxS 2944 15.12.18 10:16 Сейчас в теме

(5) Почему ED - это неверное сокращение?
Смотрим статью ИТС https://its.1c.ru/db/metod8dev#content:5851:hdoc
И видим повсеместное использование "Формат ED", "формата ED".

43. nyam-nyam 15.12.18 12:12 Сейчас в теме

(39) Проблема была не в ED, а в вариациях написания EnterpriseData - EnterpriCeData, EnterpriseDatE и т.п.

7. h00k 51 14.12.18 11:53 Сейчас в теме

Предпринимательское свидание ;)

8. w.r. 650 14.12.18 12:26 Сейчас в теме

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

9. kolya_tlt 88 14.12.18 13:12 Сейчас в теме

(8) зато вы пишете выгрузку\загрузку один раз для объекта и больше не паритесь, лишь поддерживаете изменения. когда в парке систем больше 10, и например, из 5 из них вы загружаете заказы, а в 8 - выгружаете реализации, вы сразу ощутите преимущества КД 3.0

10. kembrik 10 14.12.18 13:33 Сейчас в теме

(9) Это только в теории, к сожалению. На практике с чем только но приходится сталкиваться и править в этих "Универсальных" обменах, которые в типовых весьма безобразны. Обмениваем мы например УТ с УТ, обе базы типовые. В источнике Заказ Клиента имеет допреквизит "Поставщик" с типом СправочникСсылка.Партнеры (старндартный функционал, позволяет). В "Старой" конвертации никаких проблем, тем более у нас тут идентичные конфигурации. Положили в допреквизит -получили оттуда же. В "ED" у нас такой сущности как Партнер не имеется, правил выгрузки под нее нет, и даже механизмов, которые позволяют положить в "Строку" тип реквизита и его GUID а потом разобрать на приёмнике - тоже нет "из коробки". Худо-бедно нормально работает в типовом направлении УТ в Бух, например, но стоит только развернуть обмены в "обратную" сторону - сразу море сюрпризов

Ответить

11. kolya_tlt 88 14.12.18 13:46 Сейчас в теме

(10) вы не поняли то что я написал. я не говорил, что сложностей нет, я говорил что решаются они один раз.

22. kembrik 10 14.12.18 18:00 Сейчас в теме

(11) Увы и ах. Многообразие использования в наших типовых конфигурациях дополнительных реквизитов и сведений в самых разных вариантах таково, что мы отчаялись решить все возможные возникающие коллизии в "Универсальном обмене" постоянными допилами, а сделали отдельные обмены только допреквизитов на кд 2 для этих целей

30. MaxS 2944 14.12.18 19:16 Сейчас в теме

(22) Обмен доп реквизитами сделал на КД3. Осталось дополнить возможность обмена типами значений, не поддерживаемых форматом.
Печально, что в типовых правилах это не работает и недостаточно объектов формата, например для переноса наборов доп реквизитов и сведений.
И большой минус в функционале расширений - нельзя расширить состав плана обмена, нельзя подменить XDTO пакет. Если этот вопрос решить в будущих версиях, расширением можно будет решить все вопросы обмена.

12. w.r. 650 14.12.18 13:47 Сейчас в теме

(9) если объект в конфигурации поменялся для КД 3.0 ты должен

А) внести изменения в пакет XDTO
Б) внести измнения в ПКО в КД3.0
В) перенести код модуля обработно в конфигурацию

В своем обмене на v8msg просто вносишь изменения в код модуля загрузки и все. Выгрузка делается системой автоматически со всеми реквизитами объекта. Править ничего не надо

+ очень важно. Для обмена, основанного на ФабрикахXDTO, имеет значение порядок тэгов в файле XML! В своем обмене порядок в XML файле может быть произвольный

13. kolya_tlt 88 14.12.18 13:52 Сейчас в теме

(12)
вы забыли помножить количество действий на n-обменов. в примере выше получится минимум 5 действий, а в КД 3.0 так и останется 3. еще раз я не утверждаю что КД 2.0 плох, а 3.0 - идеален. вы же должны знать на, что способен тот или иной инструмент и что из этого следует. всё равно что сравнить пилу и бензопилу :)
насчет порядка - всё наоборот. в КД 2.0 он был важен, в 3.0 - нет

14. w.r. 650 14.12.18 14:00 Сейчас в теме

(13) это если конфигурации идентичные, то 3 действия. А если обмен БП <-> ERP, где документы не соотвествуют друг другу по структуре и реквизитам, то ПКО придется править все-равно для обеих конфигураций. + учитывайте, что для КД3.0 нужно править ПКО на выгрузку, а для обмена на v8msg - нет

21. MaxS 2944 14.12.18 17:02 Сейчас в теме

(14) не требуется синхронно менять правила КД 3.0.
Например УПП уже давно кардинально не меняется. Сделал один раз правила в КД3 и всё. Вне зависимости от появления новых документов в ERP, БП или УТ, правила в УПП не нужно дорабатывать.

24. w.r. 650 14.12.18 18:11 Сейчас в теме

(21) я писал про ERP, а не про УПП. ERP сейчас очень динамично развивающаяся конфигурация

20. MaxS 2944 14.12.18 16:57 Сейчас в теме

Приветствую всех, надеюсь как и автор, что белых пятен, заблуждений и недопониманий в использовании формата EnterpriseData будет всё меньше. ;)

(12)

В своем обмене на v8msg просто вносишь изменения в код модуля загрузки и все. Выгрузка делается системой автоматически со всеми реквизитами объекта. Править ничего не надо

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

внести изменения в пакет XDTO

- не нужно вводить людей в заблуждение. Это делать не обязательно.
Для выгрузки ссылочного объекта, который не поддерживается форматом ED тоже нашлось решение, не требующее менять пакет XDTO.

перенести код модуля обработно в конфигурацию

- для этого придумали расширения.

Никогда не задумывался о порядке тегов при использовании КД 3.0, если пользоваться БСП.

25. w.r. 650 14.12.18 18:17 Сейчас в теме

(20) это вы не вводите людей в заблуждение. Смысл КД3.0 как раз в практическом отсутствии кодинга: создал нужные объекты или доработал существующие в XDTO EnterpriseData, выгрузил получившуюся схему XSD в КД3.0. В КД3.0 мышкой нащелкал ПКО и ПОД и готово. Но по факту приходится все-равно писать сложные обработчики выгрузки и загрузки в ПКО и смысл весь как таковой в КД3.0 теряется. Работа с ним более трудоёмка чем обычный кодинг в своей процедуре загрузки XML формата v8msg

29. MaxS 2944 14.12.18 18:52 Сейчас в теме

(25) Если заниматься доработкой XDTO, то пропадает основной плюс. Слово универсальный формат можно вычеркнуть. Правда появляется другой плюс - снимаются все ограничения и появляется возможность как в КД 2 создавать правила для любых нетиповых баз.
Для вводной статьи по ED пугать людей обязательностью доработки XDTO не стоит. ;) Это не обязательная процедура, а возможность.

Сложность - понятие относительное. Специалист должен уметь всё. Применять технологии к месту, а не что-то одно, что он умеет. Для типовых конфигураций в настоящее время стандарт - универсальный формат.

32. w.r. 650 14.12.18 19:42 Сейчас в теме

(29) даже для типовых конфигураций, описанных объектов в пакете EnterpriseData, может быть недостаточно, если используются конфигурации для бюджетных учреждений и тд

На счёт сложности. На EnterpriseData есть, написанное мной, рабочее решение: экспорт/импорт справочников и документов в стороннюю ERP систему. Примерный поток несколько тысяч объектов в день и обмен v8msg. Второй вариант мне показался предпочтительнее

37. MaxS 2944 14.12.18 20:49 Сейчас в теме

(32) У каждой задачи есть решение.
Но как в статье отмечено, 1С продвигает ED. И рано или поздно типовой функционал будет работать в основных вариантах обменов и для большинства конечных пользователей этого будет достаточно. Мелкие недочеты исправят программисты.
Полностью менять типовой обмен на свой очень хороший будут единицы.

Меньше всего требуют доработок правила для БП 3.0. Видимо на обмен с БП 3.0 все типовые правила на КД3 заточены.
Самые нерабочие, по моему - правила ED для УНФ.
Требуют доработок все ERP КА УТ, розница, если настраивать обмен между собой и используются виды номенклатуры, доп реквизиты, характеристики..

38. w.r. 650 14.12.18 21:20 Сейчас в теме

(37) КД3.0 ещё не стал стандартом и, думаю, не станет им. Слишком неудобная она - требует много лишних манипуляций и нюансов в использовании. История похожая на EDT - задумка хорошая, но пользоваться невозможно

40. MaxS 2944 15.12.18 10:39 Сейчас в теме

(38) От технологичных решений не уйти, это вопрос времени. КД 3. неудобна, но это не означает, что технология ED неправильная. Если усовершенствовать КД 3, он сможет сам конструировать сложные обработки, вставлять правила в конфигурацию, тестировать обмен.
EDT аналогично - баги уберут, инструменты появятся, удобство повысится.
Возможность копаться на низшем уровне и переставлять биты информации останется, но такой ручной труд "сделать всё самому" не сможет составить конкуренцию готовым решениям.

Например, можно написать своё решение управления данными на MS Assess 2000-х годов, создать таблицы, связи, индексы, написать функционал взаимодействия с пользователем, программировать каждое действие. Или перейти на 1С и написать тоже самое. Мне приходилось этим заниматься, специально сравнивал затраты времени, чтобы обосновать переход на 1С 8.0. Разница оказалась в 8 раз в пользу 1С.
С каждым годом объёмы информации и сложность обработки будут расти, чтобы не утонуть, придётся использовать комбайны типа EDT, стандартизировать обмены как в ED и т.п.

41. w.r. 650 15.12.18 10:46 Сейчас в теме

(40) в эпоху развития REST и JSON мы говорим о «технологичных» решениях, основанных на XML и файлообмене. Ну как-то дальше даже читать не хочется. Для меня лично, касаемо интерфейсов, которые сейчас есть у 1С, более перспективным и технологичным видится интерфейс oData

42. MaxS 2944 15.12.18 11:10 Сейчас в теме

(41) Для ED не требуется обмен именно файлами. И это уже реализовано в типовых 1С. Открываем обработку "Выгрузка загрузка EnterpriseData" и видим возможность обмена текстом в виде XML. Можно в той же 1С настроить web сервисы и обмениваться в реальном времени текстом. Например, станок с ЧПУ изготавливает деталь и отправляет данные в универсальном формате в файл или в сервис, не важно. Главное он не задумывается по поводу совместимости, т.к. формат универсальный. Сегодня на том конце УПП, завтра ERP.
До появления ED синхронизация с 1С осуществлялась напрямую через com, прямыми запросами к СУБД и т.п.
Других универсальных технологичных способов обмена с типовыми базами 1С, которые поддерживаются типовыми базами пока нет. Если появится, можно будет обсуждать.

44. w.r. 650 16.12.18 21:03 Сейчас в теме

(42) web сервисы - это уже тоже вчерашний день. «Универсальность» весьма сомнительна и требует допилки напильником. Но если нравится - пользуйтесь на здоровье. Для себя за год+ использования я не нашёл особых плюсов в обмене на XSD схеме по сравнению с обычным XML

36. ids79 8535 14.12.18 20:19 Сейчас в теме

(29)Согласен, основной плюс обмена через ED, как раз стандартизация. Это, правда, и основной минус. Но здесь уж, с какой стороны смотреть.

31. kembrik 10 14.12.18 19:34 Сейчас в теме

(20)

- для этого придумали расширения.

Это которые слетают и перескакивают на стандартный модуль обмена, если в коде расширения ошибка :)?

33. w.r. 650 14.12.18 19:46 Сейчас в теме

(31) в идеальном мире от 1С, где живет в тч и Enterprise Data, ничего не слетает )))

34. ids79 8535 14.12.18 20:12 Сейчас в теме

(31)

Это которые слетают и перескакивают на стандартный модуль обмена

Расширения - механизм новый, есть конечно недочеты.
Но его уже очень многие успешно используют.
Так что Ваши опасения напрасны.

45. kembrik 10 17.12.18 11:08 Сейчас в теме

(34) Мои опасения - это недавняя боль от бардака в статьях ДДС, которые использовались в доработанном обмене по ED в расширении, для переноса того, что переносить в ED не планировали.

Расширения же тоже можно использовать по разному. Вариант один - точечно править процедуры с использованием &Вместо - подобный вариант отличный в плане контроля действа, но неудобен в разработке и поддержке. Вариант два - подменять в расширении общий модуль

 &Вместо("ДоступныеВерсииУниверсальногоФормата")
Процедура Наш_ДоступныеВерсииУниверсальногоФормата(ВерсииФормата)
   
   ВерсииФормата.Вставить("1.2", МенеджерОбменаЧерезУниверсальныйФормат);
   ВерсииФормата.Вставить("1.3", Наш_МенеджерОбменаЧерезУниверсальныйФормат);
   ВерсииФормата.Вставить("1.4", Наш_МенеджерОбменаЧерезУниверсальныйФормат);
   ВерсииФормата.Вставить("1.5", Наш_МенеджерОбменаЧерезУниверсальныйФормат);
   ВерсииФормата.Вставить("1.6", Наш_МенеджерОбменаЧерезУниверсальныйФормат);
   
КонецПроцедуры

Показать

Этот вариант удобен в разработке и поддержке но "Одно неловкое движение- и ты отец" - при ошибке в расширении есть шанс что всё пойдет по стандартной схеме

49. A_Max 20 18.12.18 15:55 Сейчас в теме

(45) простое решение вынести этот функционал в отдельное расширение.

35. MaxS 2944 14.12.18 20:16 Сейчас в теме

(31) Замечал такой момент. Давно была идея - установить второе простое расширение, которое не позволяет запускать типовые правила и генерирует ошибку. Это уже технические вопросы, которые можно решить. Для особо ответственных случаев можно просто снять модуль с правилами с поддержки и вставить свой.

23. kembrik 10 14.12.18 18:01 Сейчас в теме

(12) А что порекомендуете почитать по v8msg ? Где можно посмотреть работающие примеры обмена?

28. w.r. 650 14.12.18 18:28 Сейчас в теме

(23) почитайте, например, здесь

15. Evil Beaver 8243 14.12.18 14:44 Сейчас в теме

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

16. ids79 8535 14.12.18 16:18 Сейчас в теме

(15) Спасибо, Андрей.
Все поправил

17. ids79 8535 14.12.18 16:26 Сейчас в теме

На счет ошибки в названии всем спасибо!
Все исправил.
И за стеб тоже спасибо :)
Ибо, нефиг такие ошибки делать.
К сожалению, грамотность не мой конек.

26. rusmil 262 14.12.18 18:18 Сейчас в теме

Спасибо за статью, ждем продолжения.

27. acanta 14.12.18 18:26 Сейчас в теме

Если я поняла правильно, отладка правил обмена во второй конвертации так хорошо прижилась, что решили модуль отладчика правил превратить в глобальный модуль (чтоб наверняка отладить с перехватом и просмотром в любом месте). А насчет структуры куда выгружать могли хоть в ПВХ предопределенные, хоть в справочник, хоть в перечисления сделать. Решили почему бы не XDTO с пространством имен. Это круче.
Автору респект.

46. acanta 17.12.18 11:45 Сейчас в теме

Пакет XDTO можно загрузить в макет двоичными данными, mxl-xml или текстом? А модуль менеджера обмена данными вставить в обработку?

47. MaxS 2944 17.12.18 11:57 Сейчас в теме

(46) Да, можно. Все обмены на УПП, КА 1.1, УТ 10.3 и т.п. так сделал.

48. ids79 8535 17.12.18 11:58 Сейчас в теме

(46)Пакет XDTO можно выгрузить в виде xsd-схемы и вставить в макет. Модуль менеджера можно вставить в модуль внешней обработки.

50. vadim1011985 101 29.12.18 13:12 Сейчас в теме

Вопрос к знающим людям , есть задача организовать автоматический односторонний обмен 32-х баз ЗиУП с одной базой ЗиУП КОРП по расписанию. С помощью КД 2.0 я сделал правила и слил все данные из разных баз в одну КОРП тут проблем нет, все ясно и понятно. Префиксацию документов и некоторых справочников организовал непосредственно в самих правилах. Но это разовый обмен. Сейчас думаю на счет автоматического обмена и смотрю в сторону КД 3.0 и есть вопросы на сколько трудозатратно это все дело надо переносить все документы и справочники по ссылкам из хтих документов а так же их движения и некоторые регис тры сведений . Посмотрел формат ED 1.5 и 1.6 там нет большинства описаний документов из ЗиУП. С КД 2.0 тоже много заморочек не хочется после каждого обновления шерстить правила в поисках изменений + конфигурацию делать не типовой и писать правила регистрации для каждого объекта .

51. MaxS 2944 29.12.18 13:58 Сейчас в теме

(50) Можно сделать.
Из-за ограниченного описания видов документов и справочников в ED можно поступить 2-мя способами.

1. Выбрать справочник и документ формата для переноса любого справочника и документа.Например, СтатьиДДС и КорректировкаДолга.
Написать процедуры, которые упаковывают все реквизиты и табличные части в данные формата и распаковывают их обратно.
В правилах перед началом конвертации процедура проверяет наличие ПКО и самостоятельно заполняет для ПОД используемые ПКО, чтобы не заморачиваться ручным написанием кода для ПОД загрузки.

2. Заняться доработкой формата ED Например сделать формат 1.61 - за основу берем 1.6 и дорабатываем. Новый формат вставляем в расширение, модуль с новыми правилами туда же. Подобные расширения с идентичным форматом нужно вставить во все базы, участвующие в обмене.

Ещё не забыть загрузить в КД3 конфигурацию с регистрами накопления и расчета.
1-й вариант у меня получился. Написал обработку, создание правил для нового документа или справочника занимает меньше секунды ;)
2.- вариант очень затратный по объёмам. Правильно продумать состав документов и справочников. В процессе доработки и отладки нужно часто менять формат, соответственно одновременно обновлять все базы, участвующие в обмене.

52. vadim1011985 101 29.12.18 14:19 Сейчас в теме

(51) Тогда по 1 варианту получается что для каждого документа писать свои правила по упаковки данных в формат ?

53. MaxS 2944 29.12.18 14:33 Сейчас в теме

(52) В каждом документе вызов универсальной процедуры. Все ПКО таких документов выглядят идентично за исключением имени и ссылки на документ конфигурации. Процедура по метаданным разбирает состав реквизитов и табличных частей.
По трудозатратам сложно сказать про этот вариант, т.к. всё делалось в течение нескольких лет ;) Используется множество процедур. От выгрузки одного реквизита по имени эволюционировало в выгрузку документа со всеми реквизитами и табличными частями.
Недостаток первого варианта - конфигурации должны быть примерно идентичными. Если они отливаются обмен не поломается, просто данные по отличающимся реквизитам никуда не запишутся.
Плюс 2-го варианта - это правильное использование универсального формата обмена, обмен возможен между сильно отличающимися конфигурациями.

Если начинать с нуля, может быть и 2-й вариант будет быстрее. Когда начинал с 1-м вариантом, расширение не поддерживало XDTO пакеты.
Минус 2-го варианта в недостатках конфигурации КД3 - там нет как в КД2 автоматического заполнения ПКС. Всё руками. Это тоже пришлось автоматизировать.

54. vadim1011985 101 29.12.18 14:37 Сейчас в теме

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

55. MaxS 2944 29.12.18 14:42 Сейчас в теме

(54) формат, то как раз универсальный, задумка хорошая и правильная.
Инструменты для подготовки правил обмена с использованием КД3 ещё сырые. Если их довести до того, что умеет КД2, будет проще.

56. vadim1011985 101 29.12.18 14:47 Сейчас в теме

(55) Согласен , инструментария не хватает ,Да и инфы не так много , все рассматривают типовые примеры УТ-БП , В общем и целом понятно , но как доходит до дела... сразу куча вопросов. Еще раз спасибо за ответы

58. ids79 8535 29.12.18 18:07 Сейчас в теме

(54)Я бы на Вашем месте все-таки ED использовал, если смотреть в будущее.
КД 3.0 развивается достаточно быстро. Если на данный момент КД 2.0 и удобнее, через год ситуация может поменяться.

59. vadim1011985 101 30.12.18 11:50 Сейчас в теме

(58) Проблема в том , что я сильно ограничен по времени, до конца января уже должен быть рабочий обмен ,

Я то думал что для всех документов будет соответствие с ED , а тут такой облом , а так надо разбираться как все сворачивать в другой формат и как разворачивать потом , боюсь застрять на середине. Если как говорит , Максим у него на доработки КД 3.0 ушло несколько лет , то я за полмесяца явно не разберусь.

57. ids79 8535 29.12.18 18:04 Сейчас в теме

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

60. acanta 30.12.18 12:12 Сейчас в теме

(51)

1. Выбрать справочник и документ формата для переноса любого справочника и документа.Например, СтатьиДДС и КорректировкаДолга.

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

61. MaxS 2944 30.12.18 13:39 Сейчас в теме

(60) Интересная идея. Думал ранее над таким вариантом. Проблема в том, что на момент инициализации какой версии формата какой отдать модуль правил, мы не знаем для какого узла будут использованы эти модули. Теоретически можно перед началом обмена заново устанавливать менеджер обмена.
Ещё возникала аналогичная мысль - основной обмен через ED, вспомогательный на другом плане обмена с использованием правил на КД2.

(58)

я за полмесяца явно не разберусь.

Как выгрузить много табличных частей в одну табличную часть думаю не сложно для программиста и это к КД3 не относится. Простые типы переносим как есть, ссылочные как строка уид, даже тип данных можно не указывать, главное имя реквизита и табличной части указать.
Задержка может возникнуть с КД3 если нет опыта. И для обмена ЗУП 3 - ЗУП 3 нужно создать правила для примерно 60 документов не считая справочников. Умножаем на 3 (2 ПКО и 1 ПОД), получаем гору ручного труда.

62. acanta 30.12.18 13:44 Сейчас в теме

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

63. MaxS 2944 30.12.18 13:52 Сейчас в теме

(62) вроде бы штатно для плана обмена модуль, а не для каждого узла свой модуль.

70. ids79 8535 31.12.18 15:46 Сейчас в теме

(62)Штатно да, для плана обмена. Но можно очень просто прописать отдельные для узлов.
Для этого можно использовать реквизит узла "ПутьКМенеджеруОбмена" и совсем немного доработать процедуру "ДоступныеВерсииФорматаОбмена" из модуля менеджера плана обмена.

64. acanta 30.12.18 13:58 Сейчас в теме

А жаль. Для узла модуль было бы удобнее, возникает такое чувство - либо разработчики работают на 2х мониторах(На одном висит ЕД, на другом модуль) либо один отдел или разработчик пишет(отвечает за разработку) ЕД с оглядкой на не-1с-потребителей, а потом под него другой подстраивает конвертацию втискивая их в типовые и особо не задумываясь. Скорее всего 2й вариант, но для этого его надо редактировать во внешнем редакторе, а загружать в 1с готовое. И я не понимаю, зачем некий протокол обмена с каким-либо (даже очень важным) не 1с-ным получателем жестко встраивать в каркас обмена между 1с-ными конфигурациями.
Но фактически такой вариант будет означать встраивание конвертации 3 в конфигурацию (модуль на плане обмена вместо обработчиков до и после начала обмена, модуль на часть XDTO вместо обработчиков перед началом выгрузки, после загрузки).
В конвертации данных 2 я пока тоже только осваиваюсь, не понимаю, как отключить регистрацию чего-то в штатных в правилах регистрации объектов.

65. MaxS 2944 30.12.18 14:38 Сейчас в теме

(64)

https://its.1c.ru/db/metod8dev#content:5852:hdoc
Для обмена данными через формат EnterpriseData у конфигураций, использующих "Библиотеку стандартных подсистем", есть два веб-сервиса:

EnterpriseDataUpload – упрощенный вариант для загрузки данных в информационную базу из сторонних приложений. Не требует специальных настроек на стороне конфигурации (кроме развертывания собственно веб-сервиса); однонаправленный обмен данными – ТОЛЬКО импорт данных в информационную базу.
EnterpriseDataExchange – для двустороннего обмена данными между конфигурацией и сторонним приложением. Для работы с ним необходима настройка обмена данными на стороне конфигурации.

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

66. acanta 30.12.18 14:45 Сейчас в теме

Скорее речь идет о продвинутом пользователе, который должен либо настроить обмен как есть, либо получить(купить) обновления если обмен не работает. Типовые конфигурации расходятся в направлениях - в одном нужен программист, в других нет. ED это шаг в сторону когда программисты не нужны, и они ничего не должны настраивать, не так ли?
ИМХО, конфигурации уровня КА2 и ЕРП должны иметь возможность настроек. А к примеру в БП или УНФ это будет только мешать. Но подход один.

67. MaxS 2944 30.12.18 15:21 Сейчас в теме

(66) ED это правильный шаг. Не нужно заботится о синхронном обновлении конфигурации. Это значительно облегчает жизнь простым пользователям.
Все типовые обмены в целом нормально работают. Основное назначение - обмен между разнородными базами.
В ERP и КА последних версий появились настройки для каждого узла обмена - отбор по разделам учета.
Проблемы возникают при попытке через ED обменяться однотипными базами. КА 2 - КА 2, ЗУП - ЗУП. Для КД2 наоборот - создать правила для обмена однотипными базами легко.
Последние версии ED обмениваются информацией какие виды объектов они умеют отправлять и принимать. Для универсального обмена это полезно. Не нужно отправлять лишнее.

72. muskul 13.03.19 06:26 Сейчас в теме

(67)окей гугл не проходит обмен после обновления )

71. muskul 13.03.19 06:25 Сейчас в теме

(66)Если бы теже ошибки при синхронизации и обмене были человечные а не то что сейчас можно было бы и согласится. Не каждый консультант по 1с сразу поймет что там говорится, какое свойство и почему ЕД решил не выгружать. Особенно забавно когда он два часа выгружает выгружает тысяч 20 объектов, спотыкается на каком то одном и все на смарку. При загрузке таже ситуация.
Про правила регистрации тоже хотел бы почитать.

68. acanta 30.12.18 15:27 Сейчас в теме

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

69. acanta 30.12.18 22:00 Сейчас в теме

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

73. distorshion 30 26.02.21 00:52 Сейчас в теме

XML медленное гавно .... oData как тут уже говорили по скорости в сотни раз быстрее.

74. MaxS 2944 26.02.21 04:34 Сейчас в теме

(73) После обмена данными документ нужно провести, а это 90% из всего обмена. Поэтому особой разницы нет какой используется транспорт. ED не для скорости, оно для универсальности.

75. user1140274 01.03.21 09:47 Сейчас в теме

Дмитрий, было бы здорово если бы вы на примерах в новой статье осветили новые возможности конвертации 3.1 https://1c.ru/news/info.jsp?id=28113

В КД редакции 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, а также расширять существующие. Создавать новые версии формата можно теперь непосредственно в конфигурации КД. Также существует возможность делать расширения существующей версии формата и его объектов, добавляя значения перечислений, реквизиты ключевых свойств, реквизиты табличных частей и т. д.

76. twin76 12.03.21 09:48 Сейчас в теме

1с не умеет как-то думать широко и при этом просто - они почему то усложняют все на пустом месте часто - запутывая только людей. Идея очень хорошая - с форматом общим неким - но нахрена этих куча словечек каких-то типа, сокращений, еще и на англицком:)))) А для гибкости формата можно было просто с самого начала ввести там в этот формат некий ПростоБизнесОбъект - когда человеку надо из доработанной конфигурации что-то перенести и что никаким образом не отражено в формате. И там уже можно и родителя прописать и все остальное там вообще все. Ну и соответственно при написании конвертации для загрузки так же самое - знаешь что у тебя там есть ПростоБизнесОбъект.ОченьНужныйОбъект1 и ПростоБизнесОбъект.НужныйРеквизит12 - и что они значат и что с ними делать - ну берешь его и все. Расширять существующие версии формата EnterpriseData (по русски-то нельзя было, и чтобы смысла побольше??? - например УниверсальныйФорматОбмена??:))))))) - это примерно тоже самое может. НО по смыслу - как-то посложнее вообще - а тут, с наличием ПростоБизнесОбъекта - тут ты вообще не паришься - просто вводишь эти ПростоБизнесОбъекты на то, что в формате не описано - и все. И - вот тебе гибкость, которая утеряна в EnterpriseData (аааа, бесит!!!:))) и которая была до этого - возвращается, легко и непринужденно:))) Короче - в 1С не понимают чего-то такого Очень Важного В Жизни:)))) Судя вообще по всему, как и что у них делается:))) ВСЕ делается:)

77. twin76 12.03.21 09:53 Сейчас в теме

(76) на всякий случай скажу, что я не очень глубоко понимаю это все - но я думаю это вряд ли может помешать понять общие принципы, как это все могло бы работать лучше.

79. twin76 12.03.21 18:30 Сейчас в теме

(76)тут немного засомневался - может есть в этом ЕД (буду по русски назло 1С:))) какой-нибудь механизм передачи неописанных в формате сущностей?? Может сделали в более поздних? А то так - ну вот как раз про это человек и пишет " В "ED" у нас такой сущности как Партнер не имеется, правил выгрузки под нее нет, и даже механизмов, которые позволяют положить в "Строку" тип реквизита и его GUID а потом разобрать на приёмнике - тоже нет "из коробки"" - да это же нонсенс вообще. Ну что это за "универсальный формат"??? Вообще- я говорю- вот смотришь на 1С и думаешь - ну почему там людям - которые сверху стоят, проектировщики - такие ОЧЕВИДНЫЕ ВЕЩИ в голову не приходят???
Ну или у них какая-нибудь хитрая вообще бизнес-модель или вообще там какая-то модель существования - что надо все чтобы было через ж:)))))
Просто очень обидно, что вроде как основа-то есть - очень хорошая, заложенная еще с 7-ки, а вот реализация - гораздо хуже, чем могла бы быть.

80. MaxS 2944 12.03.21 20:01 Сейчас в теме

(79) В типовых конфигурациях в обработке "Выгрузка загрузка EnterpriseData" появилось поле "Расширение формата", в документации на БСП есть какое-то описание. И в демо базе БСП есть пример.
Задумка хорошая, но как это расширение формата использовать в синхронизации через планы обмена?

В доработанном мной формате есть сущности Документ.УниверсальныйДокумент, Справочник.УниверсальныйСправочник и Справочник.УниверсальныйСправочникГруппа, а так же универсальные процедуры для выгрузки всех реквизитов через "AdditionalInfo", их даже в правилах описывать не нужно - выгружается всё, что есть типовое и нетиповое.

81. twin76 13.03.21 00:54 Сейчас в теме

(80) спасибо за ответ, я сам не умею, можно сказать, программировать на 1С - не знаю ее, как среду разработки.Ну 7.7 знаю, 8-ку нет - так что не совсем понял там, ну в общих чертах - то что Вы в первой части ответили. Но вот то, что и Вы там вопрос задали - как это использовать, плюс то, что именно ВЫ доработали-добавили сущности в формат нужные для универсальности обмена, а не сами 1С-ники - ну это вот как раз говорит о том, что нет у них там человека который бы вот так вот сверху это все видел - довольно очевидное, со смыслом очевидным. Я вот занимаюсь на некотором уровне внедрением там-администрированием 1С, - ну там установить, косяки исправить какие-то, глюки, подключить оборудование,обновить, выгрузки настроить, показать людям, как что делать - ну кое на что хватает знаний моих - и просто постоянно сталкиваюсь с тем, что очевидные вещи или не продуманны в 1С или кажется так, что ради поступления денег все так глючно сделали:)))
Не понятно - почему вот не собраться и не обсудить им там - как бы вот например и что можно было сделать лучше - реализовать эту идею с универсальным обменом - СРАЗУ, с самого начала. А не так вот - о, идея хорошая, запускаем - и потом и через годы там не всегда появляется нормальная реализация, прям такая хорошая. В принципе на 8-ку многие люди не решались переходить и через 5 лет после ее появления - говоря, что она сырая, хотя возможностей там уже было больше. Ну ладно, это я уже далеко отошел от темы вопроса:))) Спасибо Вам - на самом деле прояснили многое -я как раз хотел понять - в чем разница между простым обменом, который есть например в ЗУП при настройке синхронизации и ED, теперь знаю, спасибо:) и думаю многие Вам тоже спасибо скажут (жалко что не сами 1С:)) - за то, что вот продвигаете -поясняете про ED

78. twin76 12.03.21 10:11 Сейчас в теме

и просто про то, что данные, выгружаются в виде, что к каждому значению полагается туева хуча символов каких-то - ну вы поняли, я про XML - и это потом все нужно как говорится парсить-разбирать и все это понимаешь, когда матами покрываешь разрабочиков, когда это все ждешь и веришь-надеешься, чтобы очередной ошибки не вылезло - ну это идиотизм просто - по другому не скажешь. Ну надо вам формат данных описывать - ну прилагайте его к файлу обмена, кто мешает то. Надо вам понты-типа-совместимость там с какими-то другими системами - хотя этот данный файл обмена им в принципе не может предназначаться - ну сделайте вы такую ВОЗМОЖНОСТЬ - если вы понторез - выгружайте через XML:)))) А если у человека тупо есть две проги и они обмениваются через 5 минут данными, миллиардами байтиков - то делать процентов 70 из этих байтиков просто бессмысленными - ну это.... как хотите, так и называйте:)))) описал в заголовке файла обмена какие данные в каких таблицах двумерных лежат и все. ну и там как значения записаны. Если там удобнее в каких-то мест не через двумерные таблицы - ну напишите, тут начинается XML - и добавьте так. Но большинство то данных- это что???? Это тупые таблички по совершенно тупым вот этим жестким описаниям. По заголовкам - что это за данные по строчкам - экземпляры данных. Собственно как оно в разных СУБД и хранится. Короче 1С-ники, еще раз говорю - чего-то важного в жизни не понимают:))) гоняются все время якобы за чем то крутым, но в итоге - совершенно простое что-то у них упускается в их всех решениях. И они получаются какими-то громоздкими и глючными и много где вообще фиг поймешь - зачем это тут вообще так сделали. Сложно и глючно. И про глюки - к этим глюкам они как-то с недостаточной серьезностью относятся - и с годами их если и убавляется в одном месте- прибавляется в другом:))) Я не только про глюки в программах - но типа того, что выпустили обновление - накатили, чуть поработали, поняли - что глючное-ошибок полно- и начинаются пляски, за которые, конечно же надо платить специалистам:))) А потом выясняется, что там в коде какая-то ерунда явная - просто надо было внимания больше уделить. Ну это люди все ЧУВСТВУЮТ. Что вот у вас такая система. И за это - вы хотите еще больше денег - чтобы вот так вот "поддерживать". И часто кажется, что именно так и было задумана - такая "бизнес модель" у 1С.

82. firml 05.07.21 04:54 Сейчас в теме

(78)

гоняются все время якобы за чем то крутым, но в итоге - совершенно простое что-то у них упускается в их всех решениях. И они получаются какими-то громоздкими и глючными и много где вообще фиг поймешь - зачем это тут вообще так сделали. Сложно и глючно. И про глюки - к этим глюкам они как-то с недостаточной серьезностью относятся - и с годами их если и убавляется в одном месте- прибавляется в другом:))) Я не только про глюки в программах - но типа того, что выпустили обновление - накатили, чуть поработали, поняли - что глючное-ошибок полно- и начинаются пляски, за которые, конечно же надо платить специалистам:))) А потом выясняется, что там в коде какая-то ерунда явная - просто надо было внимания больше уделить. Ну это люди все ЧУВСТВУЮТ. Что вот у вас такая система. И за это - вы хотите еще больше денег - чтобы вот так вот "поддерживать". И часто кажется, что именно так и было задумана - такая "бизнес модель" у 1С.

Точно, 100%! Не убавить, как говориться, не прибавить...

Оставьте свое сообщение

E-mail:

Автор:

Дмитрий Иванов (ids79)

Рейтинг: 8535

Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот

Публикация:

№ 963164

Создание 14.12.18 10:06

Обновление 16.09.19 21:27

Статистика:

Просмотры 77732

Загрузки 0

Рейтинг 308

Комментарии 84

Характеристики:

Код открыт Да

Рубрики Файловый обмен (TXT, XML, DBF), FTP

Кому Программист

Тип файла Нет файла

Платформа Платформа 1С v8.3 ,
Управляемые формы

Конфигурация Не имеет значения

Операционная система Не имеет значения

Страна Россия

Отрасль Не имеет значения

Налоги Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)