0. ids79 2066 14.12.18 10:06 Сейчас в теме

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

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

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. genayo 14.12.18 10:08 Сейчас в теме
Поправьте заголовок, ну не серьёзно же...
rpgshnik; Evil Beaver; accounting_cons; Fox-trot; +4 Ответить
3. genayo 14.12.18 10:28 Сейчас в теме
(1) Э... Не намного лучше стало...
18. ids79 2066 14.12.18 16:29 Сейчас в теме
2. Fox-trot 99 14.12.18 10:14 Сейчас в теме
так там и картинки надо тогда менять
4. MuI_I_Ika 627 14.12.18 10:52 Сейчас в теме
Да, новый формат корпоративной даты это сильно.
6. kembrik 2 14.12.18 11:48 Сейчас в теме
(4) ВходнойПрайс тоже норм)
5. nyam-nyam 14.12.18 11:16 Сейчас в теме
Уважаемый автор!
Буду весьма признателен за исправление во всём тексте и картинках/слайдах всяких разных вариаций на тему написания ED на единственно верный вариант - EnterpriseData.
razmochaev; +1 Ответить
19. ids79 2066 14.12.18 16:30 Сейчас в теме
39. MaxS 1606 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 37 14.12.18 11:53 Сейчас в теме
Предпринимательское свидание ;)
8. w.r. 213 14.12.18 12:26 Сейчас в теме
Уже больше года использую обмен на КД 3.0 с внешней системой. Из явных минусов - сложность. Нужно описывать объекты в пакете XDTO по заданным правилам, их типы + сама по себе конфигурация КД 3.0 довольно сырая: окна обработчиков - обычные текстовые поля, в которых нет даже подсветки синтаксиса. Проще реализовать свой обмен через типовой механизм обмена v8msg
VladC#; Lem0n; +2 Ответить
9. kolya_tlt 11 14.12.18 13:12 Сейчас в теме
(8) зато вы пишете выгрузку\загрузку один раз для объекта и больше не паритесь, лишь поддерживаете изменения. когда в парке систем больше 10, и например, из 5 из них вы загружаете заказы, а в 8 - выгружаете реализации, вы сразу ощутите преимущества КД 3.0
10. kembrik 2 14.12.18 13:33 Сейчас в теме
(9) Это только в теории, к сожалению. На практике с чем только но приходится сталкиваться и править в этих "Универсальных" обменах, которые в типовых весьма безобразны. Обмениваем мы например УТ с УТ, обе базы типовые. В источнике Заказ Клиента имеет допреквизит "Поставщик" с типом СправочникСсылка.Партнеры (старндартный функционал, позволяет). В "Старой" конвертации никаких проблем, тем более у нас тут идентичные конфигурации. Положили в допреквизит -получили оттуда же. В "ED" у нас такой сущности как Партнер не имеется, правил выгрузки под нее нет, и даже механизмов, которые позволяют положить в "Строку" тип реквизита и его GUID а потом разобрать на приёмнике - тоже нет "из коробки". Худо-бедно нормально работает в типовом направлении УТ в Бух, например, но стоит только развернуть обмены в "обратную" сторону - сразу море сюрпризов
svilsa; Vladimir Litvinenko; +2 Ответить
11. kolya_tlt 11 14.12.18 13:46 Сейчас в теме
(10) вы не поняли то что я написал. я не говорил, что сложностей нет, я говорил что решаются они один раз.
22. kembrik 2 14.12.18 18:00 Сейчас в теме
(11) Увы и ах. Многообразие использования в наших типовых конфигурациях дополнительных реквизитов и сведений в самых разных вариантах таково, что мы отчаялись решить все возможные возникающие коллизии в "Универсальном обмене" постоянными допилами, а сделали отдельные обмены только допреквизитов на кд 2 для этих целей
30. MaxS 1606 14.12.18 19:16 Сейчас в теме
(22) Обмен доп реквизитами сделал на КД3. Осталось дополнить возможность обмена типами значений, не поддерживаемых форматом.
Печально, что в типовых правилах это не работает и недостаточно объектов формата, например для переноса наборов доп реквизитов и сведений.
И большой минус в функционале расширений - нельзя расширить состав плана обмена, нельзя подменить XDTO пакет. Если этот вопрос решить в будущих версиях, расширением можно будет решить все вопросы обмена.
svilsa; A_Max; +2 Ответить
12. w.r. 213 14.12.18 13:47 Сейчас в теме
(9) если объект в конфигурации поменялся для КД 3.0 ты должен

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

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

+ очень важно. Для обмена, основанного на ФабрикахXDTO, имеет значение порядок тэгов в файле XML! В своем обмене порядок в XML файле может быть произвольный
13. kolya_tlt 11 14.12.18 13:52 Сейчас в теме
(12)
вы забыли помножить количество действий на n-обменов. в примере выше получится минимум 5 действий, а в КД 3.0 так и останется 3. еще раз я не утверждаю что КД 2.0 плох, а 3.0 - идеален. вы же должны знать на, что способен тот или иной инструмент и что из этого следует. всё равно что сравнить пилу и бензопилу :)
насчет порядка - всё наоборот. в КД 2.0 он был важен, в 3.0 - нет
14. w.r. 213 14.12.18 14:00 Сейчас в теме
(13) это если конфигурации идентичные, то 3 действия. А если обмен БП <-> ERP, где документы не соотвествуют друг другу по структуре и реквизитам, то ПКО придется править все-равно для обеих конфигураций. + учитывайте, что для КД3.0 нужно править ПКО на выгрузку, а для обмена на v8msg - нет
Vladimir Litvinenko; +1 Ответить
21. MaxS 1606 14.12.18 17:02 Сейчас в теме
(14) не требуется синхронно менять правила КД 3.0.
Например УПП уже давно кардинально не меняется. Сделал один раз правила в КД3 и всё. Вне зависимости от появления новых документов в ERP, БП или УТ, правила в УПП не нужно дорабатывать.
24. w.r. 213 14.12.18 18:11 Сейчас в теме
(21) я писал про ERP, а не про УПП. ERP сейчас очень динамично развивающаяся конфигурация
20. MaxS 1606 14.12.18 16:57 Сейчас в теме
Приветствую всех, надеюсь как и автор, что белых пятен, заблуждений и недопониманий в использовании формата EnterpriseData будет всё меньше. ;)

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

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

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

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

Никогда не задумывался о порядке тегов при использовании КД 3.0, если пользоваться БСП.
25. w.r. 213 14.12.18 18:17 Сейчас в теме
(20) это вы не вводите людей в заблуждение. Смысл КД3.0 как раз в практическом отсутствии кодинга: создал нужные объекты или доработал существующие в XDTO EnterpriseData, выгрузил получившуюся схему XSD в КД3.0. В КД3.0 мышкой нащелкал ПКО и ПОД и готово. Но по факту приходится все-равно писать сложные обработчики выгрузки и загрузки в ПКО и смысл весь как таковой в КД3.0 теряется. Работа с ним более трудоёмка чем обычный кодинг в своей процедуре загрузки XML формата v8msg
29. MaxS 1606 14.12.18 18:52 Сейчас в теме
(25) Если заниматься доработкой XDTO, то пропадает основной плюс. Слово универсальный формат можно вычеркнуть. Правда появляется другой плюс - снимаются все ограничения и появляется возможность как в КД 2 создавать правила для любых нетиповых баз.
Для вводной статьи по ED пугать людей обязательностью доработки XDTO не стоит. ;) Это не обязательная процедура, а возможность.

Сложность - понятие относительное. Специалист должен уметь всё. Применять технологии к месту, а не что-то одно, что он умеет. Для типовых конфигураций в настоящее время стандарт - универсальный формат.
32. w.r. 213 14.12.18 19:42 Сейчас в теме
(29) даже для типовых конфигураций, описанных объектов в пакете EnterpriseData, может быть недостаточно, если используются конфигурации для бюджетных учреждений и тд

На счёт сложности. На EnterpriseData есть, написанное мной, рабочее решение: экспорт/импорт справочников и документов в стороннюю ERP систему. Примерный поток несколько тысяч объектов в день и обмен v8msg. Второй вариант мне показался предпочтительнее
37. MaxS 1606 14.12.18 20:49 Сейчас в теме
(32) У каждой задачи есть решение.
Но как в статье отмечено, 1С продвигает ED. И рано или поздно типовой функционал будет работать в основных вариантах обменов и для большинства конечных пользователей этого будет достаточно. Мелкие недочеты исправят программисты.
Полностью менять типовой обмен на свой очень хороший будут единицы.

Меньше всего требуют доработок правила для БП 3.0. Видимо на обмен с БП 3.0 все типовые правила на КД3 заточены.
Самые нерабочие, по моему - правила ED для УНФ.
Требуют доработок все ERP КА УТ, розница, если настраивать обмен между собой и используются виды номенклатуры, доп реквизиты, характеристики..
38. w.r. 213 14.12.18 21:20 Сейчас в теме
(37) КД3.0 ещё не стал стандартом и, думаю, не станет им. Слишком неудобная она - требует много лишних манипуляций и нюансов в использовании. История похожая на EDT - задумка хорошая, но пользоваться невозможно
40. MaxS 1606 15.12.18 10:39 Сейчас в теме
(38) От технологичных решений не уйти, это вопрос времени. КД 3. неудобна, но это не означает, что технология ED неправильная. Если усовершенствовать КД 3, он сможет сам конструировать сложные обработки, вставлять правила в конфигурацию, тестировать обмен.
EDT аналогично - баги уберут, инструменты появятся, удобство повысится.
Возможность копаться на низшем уровне и переставлять биты информации останется, но такой ручной труд "сделать всё самому" не сможет составить конкуренцию готовым решениям.

Например, можно написать своё решение управления данными на MS Assess 2000-х годов, создать таблицы, связи, индексы, написать функционал взаимодействия с пользователем, программировать каждое действие. Или перейти на 1С и написать тоже самое. Мне приходилось этим заниматься, специально сравнивал затраты времени, чтобы обосновать переход на 1С 8.0. Разница оказалась в 8 раз в пользу 1С.
С каждым годом объёмы информации и сложность обработки будут расти, чтобы не утонуть, придётся использовать комбайны типа EDT, стандартизировать обмены как в ED и т.п.
41. w.r. 213 15.12.18 10:46 Сейчас в теме
(40) в эпоху развития REST и JSON мы говорим о «технологичных» решениях, основанных на XML и файлообмене. Ну как-то дальше даже читать не хочется. Для меня лично, касаемо интерфейсов, которые сейчас есть у 1С, более перспективным и технологичным видится интерфейс oData
42. MaxS 1606 15.12.18 11:10 Сейчас в теме
(41) Для ED не требуется обмен именно файлами. И это уже реализовано в типовых 1С. Открываем обработку "Выгрузка загрузка EnterpriseData" и видим возможность обмена текстом в виде XML. Можно в той же 1С настроить web сервисы и обмениваться в реальном времени текстом. Например, станок с ЧПУ изготавливает деталь и отправляет данные в универсальном формате в файл или в сервис, не важно. Главное он не задумывается по поводу совместимости, т.к. формат универсальный. Сегодня на том конце УПП, завтра ERP.
До появления ED синхронизация с 1С осуществлялась напрямую через com, прямыми запросами к СУБД и т.п.
Других универсальных технологичных способов обмена с типовыми базами 1С, которые поддерживаются типовыми базами пока нет. Если появится, можно будет обсуждать.
44. w.r. 213 16.12.18 21:03 Сейчас в теме
(42) web сервисы - это уже тоже вчерашний день. «Универсальность» весьма сомнительна и требует допилки напильником. Но если нравится - пользуйтесь на здоровье. Для себя за год+ использования я не нашёл особых плюсов в обмене на XSD схеме по сравнению с обычным XML
36. ids79 2066 14.12.18 20:19 Сейчас в теме
(29)Согласен, основной плюс обмена через ED, как раз стандартизация. Это, правда, и основной минус. Но здесь уж, с какой стороны смотреть.
31. kembrik 2 14.12.18 19:34 Сейчас в теме
(20)
- для этого придумали расширения.


Это которые слетают и перескакивают на стандартный модуль обмена, если в коде расширения ошибка :)?
33. w.r. 213 14.12.18 19:46 Сейчас в теме
(31) в идеальном мире от 1С, где живет в тч и Enterprise Data, ничего не слетает )))
34. ids79 2066 14.12.18 20:12 Сейчас в теме
(31)
Это которые слетают и перескакивают на стандартный модуль обмена


Расширения - механизм новый, есть конечно недочеты.
Но его уже очень многие успешно используют.
Так что Ваши опасения напрасны.
45. kembrik 2 17.12.18 11:08 Сейчас в теме
(34) Мои опасения - это недавняя боль от бардака в статьях ДДС, которые использовались в доработанном обмене по ED в расширении, для переноса того, что переносить в ED не планировали.

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

 &Вместо("ДоступныеВерсииУниверсальногоФормата")
Процедура Наш_ДоступныеВерсииУниверсальногоФормата(ВерсииФормата)
   
   ВерсииФормата.Вставить("1.2", МенеджерОбменаЧерезУниверсальныйФормат);
   ВерсииФормата.Вставить("1.3", Наш_МенеджерОбменаЧерезУниверсальныйФормат);
   ВерсииФормата.Вставить("1.4", Наш_МенеджерОбменаЧерезУниверсальныйФормат);
   ВерсииФормата.Вставить("1.5", Наш_МенеджерОбменаЧерезУниверсальныйФормат);
   ВерсииФормата.Вставить("1.6", Наш_МенеджерОбменаЧерезУниверсальныйФормат);
   
КонецПроцедуры
Показать
Этот вариант удобен в разработке и поддержке но "Одно неловкое движение- и ты отец" - при ошибке в расширении есть шанс что всё пойдет по стандартной схеме
49. A_Max 16 18.12.18 15:55 Сейчас в теме
(45) простое решение вынести этот функционал в отдельное расширение.
35. MaxS 1606 14.12.18 20:16 Сейчас в теме
(31) Замечал такой момент. Давно была идея - установить второе простое расширение, которое не позволяет запускать типовые правила и генерирует ошибку. Это уже технические вопросы, которые можно решить. Для особо ответственных случаев можно просто снять модуль с правилами с поддержки и вставить свой.
23. kembrik 2 14.12.18 18:01 Сейчас в теме
(12) А что порекомендуете почитать по v8msg ? Где можно посмотреть работающие примеры обмена?
28. w.r. 213 14.12.18 18:28 Сейчас в теме
15. Evil Beaver 5774 14.12.18 14:44 Сейчас в теме
Формат называется EnterpriseData. Исправьте заголовок, потому что потенциальные читатели, которые будут искать на инфостарте информацию - не смогут найти Вашу статью.
16. ids79 2066 14.12.18 16:18 Сейчас в теме
(15) Спасибо, Андрей.
Все поправил
17. ids79 2066 14.12.18 16:26 Сейчас в теме
На счет ошибки в названии всем спасибо!
Все исправил.
И за стеб тоже спасибо :)
Ибо, нефиг такие ошибки делать.
К сожалению, грамотность не мой конек.
26. rusmil 145 14.12.18 18:18 Сейчас в теме
Спасибо за статью, ждем продолжения.
27. acanta 56 14.12.18 18:26 Сейчас в теме
Если я поняла правильно, отладка правил обмена во второй конвертации так хорошо прижилась, что решили модуль отладчика правил превратить в глобальный модуль (чтоб наверняка отладить с перехватом и просмотром в любом месте). А насчет структуры куда выгружать могли хоть в ПВХ предопределенные, хоть в справочник, хоть в перечисления сделать. Решили почему бы не XDTO с пространством имен. Это круче.
Автору респект.
46. acanta 56 17.12.18 11:45 Сейчас в теме
Пакет XDTO можно загрузить в макет двоичными данными, mxl-xml или текстом? А модуль менеджера обмена данными вставить в обработку?
47. MaxS 1606 17.12.18 11:57 Сейчас в теме
(46) Да, можно. Все обмены на УПП, КА 1.1, УТ 10.3 и т.п. так сделал.
48. ids79 2066 17.12.18 11:58 Сейчас в теме
(46)Пакет XDTO можно выгрузить в виде xsd-схемы и вставить в макет. Модуль менеджера можно вставить в модуль внешней обработки.
A_Max; acanta; +2 Ответить
50. vadim1011985 65 29.12.18 13:12 Сейчас в теме
Вопрос к знающим людям , есть задача организовать автоматический односторонний обмен 32-х баз ЗиУП с одной базой ЗиУП КОРП по расписанию. С помощью КД 2.0 я сделал правила и слил все данные из разных баз в одну КОРП тут проблем нет, все ясно и понятно. Префиксацию документов и некоторых справочников организовал непосредственно в самих правилах. Но это разовый обмен. Сейчас думаю на счет автоматического обмена и смотрю в сторону КД 3.0 и есть вопросы на сколько трудозатратно это все дело надо переносить все документы и справочники по ссылкам из хтих документов а так же их движения и некоторые регис тры сведений . Посмотрел формат ED 1.5 и 1.6 там нет большинства описаний документов из ЗиУП. С КД 2.0 тоже много заморочек не хочется после каждого обновления шерстить правила в поисках изменений + конфигурацию делать не типовой и писать правила регистрации для каждого объекта .
51. MaxS 1606 29.12.18 13:58 Сейчас в теме
(50) Можно сделать.
Из-за ограниченного описания видов документов и справочников в ED можно поступить 2-мя способами.

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

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

Ещё не забыть загрузить в КД3 конфигурацию с регистрами накопления и расчета.
1-й вариант у меня получился. Написал обработку, создание правил для нового документа или справочника занимает меньше секунды ;)
2.- вариант очень затратный по объёмам. Правильно продумать состав документов и справочников. В процессе доработки и отладки нужно часто менять формат, соответственно одновременно обновлять все базы, участвующие в обмене.
52. vadim1011985 65 29.12.18 14:19 Сейчас в теме
(51) Тогда по 1 варианту получается что для каждого документа писать свои правила по упаковки данных в формат ?
53. MaxS 1606 29.12.18 14:33 Сейчас в теме
(52) В каждом документе вызов универсальной процедуры. Все ПКО таких документов выглядят идентично за исключением имени и ссылки на документ конфигурации. Процедура по метаданным разбирает состав реквизитов и табличных частей.
По трудозатратам сложно сказать про этот вариант, т.к. всё делалось в течение нескольких лет ;) Используется множество процедур. От выгрузки одного реквизита по имени эволюционировало в выгрузку документа со всеми реквизитами и табличными частями.
Недостаток первого варианта - конфигурации должны быть примерно идентичными. Если они отливаются обмен не поломается, просто данные по отличающимся реквизитам никуда не запишутся.
Плюс 2-го варианта - это правильное использование универсального формата обмена, обмен возможен между сильно отличающимися конфигурациями.

Если начинать с нуля, может быть и 2-й вариант будет быстрее. Когда начинал с 1-м вариантом, расширение не поддерживало XDTO пакеты.
Минус 2-го варианта в недостатках конфигурации КД3 - там нет как в КД2 автоматического заполнения ПКС. Всё руками. Это тоже пришлось автоматизировать.
54. vadim1011985 65 29.12.18 14:37 Сейчас в теме
(53) Спасибо. Скорее всего придется все таки КД 2.0 юзать, так как по срокам очень ограничен , Как по мне , КД 3.0 не такой уж и универсальный формат как его позиционируют (((.
55. MaxS 1606 29.12.18 14:42 Сейчас в теме
(54) формат, то как раз универсальный, задумка хорошая и правильная.
Инструменты для подготовки правил обмена с использованием КД3 ещё сырые. Если их довести до того, что умеет КД2, будет проще.
56. vadim1011985 65 29.12.18 14:47 Сейчас в теме
(55) Согласен , инструментария не хватает ,Да и инфы не так много , все рассматривают типовые примеры УТ-БП , В общем и целом понятно , но как доходит до дела... сразу куча вопросов. Еще раз спасибо за ответы
58. ids79 2066 29.12.18 18:07 Сейчас в теме
(54)Я бы на Вашем месте все-таки ED использовал, если смотреть в будущее.
КД 3.0 развивается достаточно быстро. Если на данный момент КД 2.0 и удобнее, через год ситуация может поменяться.
59. vadim1011985 65 30.12.18 11:50 Сейчас в теме
(58) Проблема в том , что я сильно ограничен по времени, до конца января уже должен быть рабочий обмен ,

Я то думал что для всех документов будет соответствие с ED , а тут такой облом , а так надо разбираться как все сворачивать в другой формат и как разворачивать потом , боюсь застрять на середине. Если как говорит , Максим у него на доработки КД 3.0 ушло несколько лет , то я за полмесяца явно не разберусь.
57. ids79 2066 29.12.18 18:04 Сейчас в теме
(53)Мне больше импанирует первый вариант, без доработки формата. Хотя конечно есть тоже нюансы. Наверно разработчикам имеет смысл создать специальные объекты формата для удобного переноса произвольных данных. Как раз для таких случаев. Ну и функционал КД 3.0 слабоват конечно. Хотя лучше, чем пару лет назад.
60. acanta 56 30.12.18 12:12 Сейчас в теме
(51)
1. Выбрать справочник и документ формата для переноса любого справочника и документа.Например, СтатьиДДС и КорректировкаДолга.

И спустя еще несколько лет мы получим ситуацию как с правами доступа (вместо набора прав - кирпичики, объединяемые в профиль, сохраняемый в пользовательском режиме).
Разбиваем EnterpriseData на подсистемы или даже отдельные объекты, для каждого пишем отдельный собственный формат. Унификация сохранится, в случае несинхронного обновления корреспондентов (как у нас часто бывает) можно будет отключить нерабочие участки в режиме предприятия.
61. MaxS 1606 30.12.18 13:39 Сейчас в теме
(60) Интересная идея. Думал ранее над таким вариантом. Проблема в том, что на момент инициализации какой версии формата какой отдать модуль правил, мы не знаем для какого узла будут использованы эти модули. Теоретически можно перед началом обмена заново устанавливать менеджер обмена.
Ещё возникала аналогичная мысль - основной обмен через ED, вспомогательный на другом плане обмена с использованием правил на КД2.

(58)
я за полмесяца явно не разберусь.
Как выгрузить много табличных частей в одну табличную часть думаю не сложно для программиста и это к КД3 не относится. Простые типы переносим как есть, ссылочные как строка уид, даже тип данных можно не указывать, главное имя реквизита и табличной части указать.
Задержка может возникнуть с КД3 если нет опыта. И для обмена ЗУП 3 - ЗУП 3 нужно создать правила для примерно 60 документов не считая справочников. Умножаем на 3 (2 ПКО и 1 ПОД), получаем гору ручного труда.
62. acanta 56 30.12.18 13:44 Сейчас в теме
Почему нельзя прописать в свойствах формата модуль правил обмена? В подписках на событие определяется модуль, а тут некуда его определить?
63. MaxS 1606 30.12.18 13:52 Сейчас в теме
(62) вроде бы штатно для плана обмена модуль, а не для каждого узла свой модуль.
70. ids79 2066 31.12.18 15:46 Сейчас в теме
(62)Штатно да, для плана обмена. Но можно очень просто прописать отдельные для узлов.
Для этого можно использовать реквизит узла "ПутьКМенеджеруОбмена" и совсем немного доработать процедуру "ДоступныеВерсииФорматаОбмена" из модуля менеджера плана обмена.
64. acanta 56 30.12.18 13:58 Сейчас в теме
А жаль. Для узла модуль было бы удобнее, возникает такое чувство - либо разработчики работают на 2х мониторах(На одном висит ЕД, на другом модуль) либо один отдел или разработчик пишет(отвечает за разработку) ЕД с оглядкой на не-1с-потребителей, а потом под него другой подстраивает конвертацию втискивая их в типовые и особо не задумываясь. Скорее всего 2й вариант, но для этого его надо редактировать во внешнем редакторе, а загружать в 1с готовое. И я не понимаю, зачем некий протокол обмена с каким-либо (даже очень важным) не 1с-ным получателем жестко встраивать в каркас обмена между 1с-ными конфигурациями.
Но фактически такой вариант будет означать встраивание конвертации 3 в конфигурацию (модуль на плане обмена вместо обработчиков до и после начала обмена, модуль на часть XDTO вместо обработчиков перед началом выгрузки, после загрузки).
В конвертации данных 2 я пока тоже только осваиваюсь, не понимаю, как отключить регистрацию чего-то в штатных в правилах регистрации объектов.
65. MaxS 1606 30.12.18 14:38 Сейчас в теме
(64)
https://its.1c.ru/db/metod8dev#content:5852:hdoc
Для обмена данными через формат EnterpriseData у конфигураций, использующих "Библиотеку стандартных подсистем", есть два веб-сервиса:

EnterpriseDataUpload – упрощенный вариант для загрузки данных в информационную базу из сторонних приложений. Не требует специальных настроек на стороне конфигурации (кроме развертывания собственно веб-сервиса); однонаправленный обмен данными – ТОЛЬКО импорт данных в информационную базу.
EnterpriseDataExchange – для двустороннего обмена данными между конфигурацией и сторонним приложением. Для работы с ним необходима настройка обмена данными на стороне конфигурации.
Теоретически можно обмениваться не только с 1С.
С одной стороны это недостаток - общий модуль правил на все узлы, с другой стороны если всем дать функционал на каждый узел свои правила, то после обновления конфигурации пользователи массово забудут обновить правила и так же будут ругать новый формат обмена.
Поэтому если программист, обслуживающий обмен смог настроить для каждого узла свои правила, то он и сможет его поддерживать в рабочем состоянии.
Т.е. так, как сделано сейчас в типовых наверное логично.
66. acanta 56 30.12.18 14:45 Сейчас в теме
Скорее речь идет о продвинутом пользователе, который должен либо настроить обмен как есть, либо получить(купить) обновления если обмен не работает. Типовые конфигурации расходятся в направлениях - в одном нужен программист, в других нет. ED это шаг в сторону когда программисты не нужны, и они ничего не должны настраивать, не так ли?
ИМХО, конфигурации уровня КА2 и ЕРП должны иметь возможность настроек. А к примеру в БП или УНФ это будет только мешать. Но подход один.
67. MaxS 1606 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 56 30.12.18 15:27 Сейчас в теме
КД 2 предусматривает возможность миграции движений (т.е. перенос данных как есть, независимо от наличия исправлений в последующих периодах и последовательности проведения), КД 3 такой возможности не имеет. При настройке обмена в КД 2 с проведением в базе получателе - лучше сразу делать КД 3.
69. acanta 56 30.12.18 22:00 Сейчас в теме
В любом случае типовая конфигурация получается отражением бизнес процесса разработки конфигурации. Если при таком количестве общих модулей и возможности добавлять методы преобразования в форматы к объектам хоть в модули объектов, хоть в модули менеджера, модуль ED один и к нему построено нечто похожее на вымученную 2ю конвертацию, то таковы особенности разделения труда самих разработчиков в фирме 1с. Есть отдел интеграции, они пока поддерживают кд2 и судя по всему слабо взаимодействуют с самими разработчиками.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Санкт-Петербург
Полный день

Консультант 1С
Нижний Новгород
зарплата до 100 000 руб.
Полный день


Программист 1С
Москва
зарплата от 140 000 руб.
Полный день

Программист 1С
Бобров
зарплата от 100 000 руб. до 150 000 руб.
Временный (на проект)