Ребята, есть у кого-нибудь мысли/опыт, как можно написать одни универсальные правила обмена данных для обмена УТ->УТ и УТ->БП ? Как это теоретически делается?

нам отсыпешь?

(1) Думаешь это невозможно?

(0) ЛОЛ)))))
А что курить надо, что бы такие идеи в голову пришли?

Сразу видно что ты слабо представляешь что такое КД, раз задаешь такие глупые вопросы.

Ребята, обоснуйте! Что вы за зря пылите.

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

Да как ты сделаешь универсальные правила обмена, когда объекты в конфигурациях разные?
И главное зачем это нужно?

(5) а если объекта не будет?

(6) Например? Документ реализации и документ поступления - разные объекты, но ведь мы же может конвертнуть из одного в другое.

(5) Если Тогда Иначе КонецЕсли;
Отработать как пожелаем.

(8) реквизит в документе поступления добавили а в другом (реализации ну или наоборот документы)удалили при обновлении. Ну и что ты будешь делать тогда?

(8) Конвертнуть можем. Но это лишние обработки, мало того что это кча дополнительной возьни и отладки правил, это ещё и возрастание возможности ошибки при обмене и плюс ко всему замедление самого обмена, из-за дополнительных телодвижениях при выполнении обмена. И ради чего всё это???

тс наверное предполагает "умные" вместо "универсальные",
чтобы сами все решали что, куда и зачем конвертировать:)

(8) Такие неумелые обновления (ну или форс-мажоры) и нормальные правила обмена данных не вывезут.

(10) Ради создания универсальных правил, для клиентов с разными конфигурациями. Хотя проще будет конечно составить набор правил УТ - БП, УТ - УТ... как выход. ))

+(12) Блин... Вот только выгрузка с одной базы производится один раз, и не известно какая конфигурация у премника.

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

(13) а с помощью каких правил выгружаются ?

(14) Вы предлагаете выгружать данные два раза по двум разным правилам?

(15) Самописные.
Пока два вида выгрузки:
- Реализация товаров и услуг -> Поступление товаров и услуг
- Текущие цены -> Установка цен номенклатуры

ну если количество объектов ограничено то можно и свою загрузку написать. Я так понимаю что конфигурации загрузки тоже известны.

(16) да
лучше использовать КД так, как она задумана - упростится процесс написания

(17) конфигурации загрузки НЕ известны. (в пределах возможных)) )

(18) Вот только получается что нужно выдумывать дополнительный формат обмена, через который обмен будет универсальный. Типа как-будто через ДБФ.

(17) крайне не хочется специально что-то выдумывать. ))

(0)(20) 2 макета + переменная КонфигурацияПолучатель для примера посмотри выгрузку из ЗУП в Бухгалтерию.

(17) напиши функцию в своей самописной, которая тебе вернет наименование конфигурации + релиз

(21) Переменная КонфигурацияПолучатель заполняется при выгрузке?

Два макета, значит два правила.

(24) и что?
(23) КАК ты при выгрузке определишь получателя? если только  сам его не укаешь (радиокнопочка)

(25) проходили в (13)

Стало быть анализировать что куда загружать нужно в базе получателя.

(26) правильно мыслишь.
1 ты знаешь куда  выгружаешь
2 выгрузить все и разобрать при получении

(26) КД здесь ни при чем
пиши свою обработку

какой-то сферический конь в вакууме.

в рамках КД ты, в принципе, сможешь такое сделать, но времени убьёшь, наверное, раза в 3-4 больше, чем для написания по-отдельности всех правил вместе взятых.

самое нормальное - выгружать для всех наборов принимающих конфиг отдельные файлы, зиповать их, а принимающая выгрузка уже будет распаковывать и выбирать нужный, потом грузить станд. обработкой загр/выгр ХМЛ

Ок, ладно. Спасибо всем за участие.