Делаем обмен между УПП и ЕРП, имеет ли смысл использовать Конвертацию 3, так как в дальнейшем УПП будет заменятся, и хочется EnterpriseData. Взлетит ли EnterpriseData на 8.2?

Если дёрнешь все модули, то почему бы и нет?

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

(0) если под enterprise data  имеется ввиду чтнние ,и отдача xml а этом формате то да, ни каких сложностей.
Если скопировать модули и запустить, то нужна будет доработка напильником, там используются встроенные в платформу функции, которых нет в 8.2

ИМХО, впендюривать свежую подсистему БСП в старую конфу выйдет значительно дороже, чем ограничиться на этом этапе обменом по КД2

А в плане проблем с платформой (отсутствие каких то методов)? (2) а можно по подобнее про дописку ERP? (3) Каких функций не хватает?

(5) а как по твоему происходит дописка правил?

(0) что вы будете делать, когда понадобится обмениваться данные, которые EnterpriseData не может передавать?

тут разумнее задаваться вопросом "а что мне даст EnterpriseData и стоит ли с ней связываться вообще"

(8) Спасибо, какие данные EnterpriseData не может передавать? Мне надо аргументировать что бы отказаться от EnterpriseData, так как не я его предлагал использовать.

Ключевая проблема не в 8.2.
Всегда можно поставить 8.3, запустить на ней УПП и повысить режим совмести до минимально необходимого 8.3.хх С высокой долей вероятности никаких особых проблем при этом не возникнет.

Ключевая проблема в отсутствии в УПП нужной версии БСП.
Чтобы вкорячить в УПП все нужные куски от нужной версии БСП, придется потратить немало сил.

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

(9) >> Мне надо аргументировать что бы отказаться от EnterpriseData, так как не я его предлагал использовать.

Почему тебе это надо?....
Пусть тот, кто предлагает использовать ED, и аргументирует - для чего ему это надо.

(12) этот, который предлагает, аргументировать скорее всего не сможет, т.к. уровень владения предметом у него, судя по всему, еще меньший, чем у автора. Он просто слышал звон про универсальный формат и всё.
Я к тому, что такой подход не взлетит - автору надо дасть себе труд разобраться в деталях и таки аргументировать самому

(9) >> Мне надо аргументировать.

Аргумент простой: ED не поддерживается в УПП т.к. 8.2 и там нет нужной версии БСП. Соответствующая доработка УПП - это долго, дорого, глючно. Спрашивается - нужны ли эти затраты и риски для владельца системы и какие он получит плюшки, если всё таки решится в это вписываться.

(12) Тот кто предлагает, платит мне деньги и он выдвинул условие, что бы я аргументировал, можно или нельзя. (11) Почему тогда EnterpriseData используется в новых конфигурациях при обменах?

(15) потому, что там обмениваются те и только те данные, которые может ED и обмен какими-либо другими данными не предполагается и в помине.

(15) >> Почему тогда EnterpriseData используется в новых конфигурациях при обменах?

Потому что в этих конфигурация есть поддержка ED и соответствующих версий БСП.
В УПП этой поддержки нет.

И дополняет этот формат фирма 1С сама, когда ей это потребуется для расширения функционала типовых конфиг.

EnterpriseData был задуман для обменов между разными организациями - типа, он предоставляет всем спецификацию формата ОПРЕДЕЛННЫХ объектов, все ему следуют и могут получать друг у друга организации, номенклатуру, контрагентов, там, и прочие накладные. Для обменов разных ИС внутри одного ИТ-ландшафта есть КД, поскольку эти обмены куда гораздо более разнообразные и их зачесать под одну вшегонялку не получится

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

(15) >> Тот кто предлагает, платит мне деньги и он выдвинул условие, что бы я аргументировал, можно или нельзя.

Можно всё! Вопрос - на*уя?

>> он выдвинул условие, что бы я аргументировал

Дичь какая-то. Я выдвину условие, что все сотрудники должны каждое утро, придя на работу, биться головой об стенку в течении 10 минут. А ты аргументируй - почему этого делать не надо. Не сумеешь сделать это убедительно - пойдешь биться головой об стену?

Автор, я серьезно, потрать день и разберись сам, что именно передает ED. Насшибаешь экспириенса и получишь левелап. Всего за день.
Да, эта шляпа на голову с большим трудом налазит, но просто прими, что выхода другого нет и, стиснув зубы, читай

(20) тебе где-то по середине проекта уже и бабки эти нужны не будут, и на УПП ты смотреть не сможешь

(9) Все, которые не прописаны в тех, что может :) Открой соответствующий пакет XDTO и посмотри.
(15) Потому, что это уменьшает трудозатраты по разработке обменов в рамках текущего стека типовых. В 1С вывели некий общий знаменатель, который отвечает ИХ нуждам. И в рамках этого знаменателя и нужд, под которые его пилили (обмен документами, которыми чаще всего меняются типовые), все выглядит боль-менее красивенько. Не надо писать кучу загрузок выгрузок под все комбинации обменивающихся баз. Только даже с совместимостью между разными стеками (разными версиями EnterpriseData) уже возникают проблемы.

(22) А что именно почитать? Прочту сейчас. (23) Понял, спасибо.

(20) Технически реализовать можно всё. Это ж 1С. На ней и игры пишут.
Просто это работа (впендюривание БСП в УПП) бессмысленная, тупая и может иметь неприятные последствия в виде неявных ошибок. Это риск. У тебя в УПП будет жить одновременно две версии БСП - одна - от текущей УПП и вторая - вкоряченная для поддержки ED.

(21) заказчик хочет универсальный обмен, который в дальнейшем можно будет масштабировать и расширять без участия этого конкретного исполнителя. Это - цель. Заказчик слышал, что ED - это универсальный формат. Заказчик не знает, что у слова универсальный есть масса оговорок, по этому требует именно его. Надо объяснить челоеку, что цель его благородна и дальновидна и вообще он молодец, но средство он выбрал не то, а то - это КД.

(25) КОД

(0) некогда объяснять , обмен УПП ERP делать надо через КД 2

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

пытаться внедрять обмен на ED в УПП бессмысленная затея

спасибо, понятно, ED изучу, (28) что такое КОД, имеется в виду структура ED? Из УТ11, например?

(15)
Представь себе контейнер с товаром который приехал на склад. В нем лежат столы, стулья и лежит бумажка в которой написано что столы лежат в левом углу контейнера и их нужно положить в ячейку А1248, А стулья в правом углу и их нужно положить в ячейку Б1245. И если завтра приедет шкаф, то там же будет бумажка куда ложить этот шкаф. - это КД2

А теперь представь другой контейнер в которой все места подписаны, т.е. в этом углу шкаф, в этом стол. и нет никаких бумажек. Зато кладовщик знает что нужно из этого угла положить в ячейку А1248, а эту мебель в ячейку Б1245 - это КД3

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

Короче как то так. Т.е. EnterpriseData это четко структуированный файл определенного формата. И если ты хочешь туда что то добавить, то тебе или нужно менять формат или попытаться использовать существующие места под свои данные. Но в любом случае тебе на стороне приемника придется описывать что делать с этими данными. Для 1С которая сама пишет этот формат, ей проще в своих решениях сразу прописать что делать с этими данными в своих типовых решениях.

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

(23) >> тебе где-то по середине проекта уже и бабки эти нужны не будут

Истинная правда, 80% проектов разваливаются именно из-за самоуверенности горе-разработчика, который на середине понял, что ему не осилить и просто сваливает отмалчиваясь.

(30) Ты имеешь ввиду EnterpriseData  как разновидность CommerceML, которая была еще в 7.7

(7) Говорить, что 1С г**но, и ругаться на то, что методисты не предусмотрели, что у пользователя может зачесаться мизинец, а не пятка.

(32) код. Ну - это то, из чего программы состоят. Программный код. Буковки такие в конфигураторе. Их, если прочитаешь, то становится в конце концов понятно, что программа делает.