Добра всем.

Имеем базу БП с доработанным функционалом "сбоку" (упр. учет), в которой идет работа, ввод "белых" и "не очень" первичных данных, формирование рег. отчетности.
ГБ желает видеть рядом отдельную типовую БП с только "белой" первичкой и отчетностью, которую можно спокойно отдать фискальным органам по требованию.

РИБ не подходит из-за требования иметь в приемнике типовую БП.
Выгрузка и загрузка данных XML - не работает с планами обмена.
Универсальный обмен данными в формате XML - потребуется поддерживать правила обмена для работоспособности, а нужно сделать "раз и навсегда".

Засим вопрос общественности, каким путем можно решить задачу с минимальными телодвижениями?
Бредогенератор порождает пару вариантов решения (ниже) посредством универсального обмена данными в формате XML, но вдруг есть решение изящнее и проще.

1) административно решить вопрос с оперативным смещением даты запрета редактирования, каждую ночь перегружать данные по периоду с даты запрета редактирования по текущую;
2) включить план обмена; данные, подлежащие переносу, добавлять в ТЧ дополнительных данных к обмену выборкой из плана обмена с ручной очисткой оного в случае успешного обмена.

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

Для начала определиться, обмен между идентичными, или все таки между доработанной и типовой....

(2) Доработанной и типовой, но доработки не трогают переносимые данные.

планы обмена <> риб

(2) Я проверял в ручном режиме, выгрузка и загрузка данных XML отрабатывает корректно - объекты, соответствующие типовым метаданным, переносятся.

(4) Согласен, я обратного и не утверждал. Не понял к чему это пока.

Выгрузка и загрузка данных XML работает с планами обмена. Только там другое требование: полное совпадение метаданных.

(6) Хочешь сказать что не можешь свой план обмена создать? Дожили...

(7) >Только там другое требование: полное совпадение метаданных.

ЭЭЭто с какого перепугу то?

Перегружать белую часть в идентичную конфигурацию. При необходимости отдать, отрезать функционал который сбоку.

(7) Неа, не работает.
(9) Может туплю, у меня уже полночь. Ну сделаю я план обмена, транспортом-то что будет? Цель - с правилами НЕ заморачиваться, писал об это в исходном посте.

(10) Собственно, вопрос, как перегружать-то?

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

(12) 1.Почитать книжки по 1С...
2.Попрактиковаться в программировании на 1С...
3.Сделать.

http://v8.1c.ru/overview/Term_000000151.htm

"Назначение

В плане обмена хранится список узлов, - участников обмена в распределенной информационной системе. В качестве узлов могут выступать информационные базы 1С:Предприятия 8, информационные базы 1С:Предприятия 7.7 или другие информационные системы, не основанные на 1С:Предприятии."

(9) Если в переносимых данных, хотя бы, порядок реквизитов другой - получишь ошибку разбора XML. Так точно было в ВыгрузкаЗагрузкаXML82, в ВыгрузкаЗагрузкаXML83 я думаю тоже самое.

(16) Еще раз повторю, что подлежащие переносу данные - типовые, совпадают по структуре в источнике и приемнике.

(16) Для ТС это пофыг у него типовые одинаковые, а не типовые тупо игнорим программно и игнорим все которые касаются "фиктивной организации"

Т.е. простейший код то, вот если бы разная структура метаданных или сторонняя прога тогда да пришлось бы уметь с XML работать и(или) правила конвертации

Плюс штатных планов обмена перед КД только что не надо правила при обновлениях допиливать каждый раз.

Один раз наваял и если ничего не меняется в методах которых затрагивают определение "фиктивности организации" для объектов то синхронно обновлять тока не забывать типовые метаданные.

(19) Да, не сталкивался я со штатными обменами, пробел, даже дырища в знаниях, что касается этой области.

Как я понял пока, смотрю штатные обмены, правила КД не понадобятся, данные будут сериализоваться. Гуглю, спасибо за наводку и терпение к неразумеющему )

(20) Планы обмена когда тока начал изучать 8-ку после 77 были такой гениальной штукой для меня.

До этого на 77 свой РИБ успели изобрести с контролем изменения для каждого объекта метаданных и сверке надо ли отправлять/загружать или нет.

В 8ке все проще, изменение объекта отправляет его в "список измененных" и затем привязку к номеру сообщения для передачи. Затем при выгрузке выгружаются в очередное сообщение с новым номером +1 все объекты из неподтвержденных (типа не полученных) сообщений.

Подтверждение получения сообщения с неким номером автоматически подтверждает все меньшие номера сообщений и объекты в них.

Синхронизация между двумя БП через универсальный формат

(22) Да, практически дубль по смыслу, каюсь.

(13) есть обработки для БП "Удаление по организации"
судя по тому, что цфник надо накатывать, в этом варианте есть доля ручного труда, поэтому запустить обработку думаю не проблема
я делал похожее, запуск обработки после обмена, иногда обмен притаскивал ненужные доки по связанным ссылкам

(с) Обмен "нужно сделать "раз и навсегда""
нет сынок это фантастика

(0) Можно сделать риб, и во второй базе иметь только белые операции, а как придет время отдавать на проверку накатывать типовую и отдавать базу

(21) понятен твой энтузиазм, но самому пришлось попытаться решить на практике задачу как у ТС - могу только кратко сказать, что это нетривиальная задача.

(26) сделать-то можно. Но что будет после периодических обновлений типовых механизмов? Это не будет решением "раз и навсегда". Я в итоге решил вообще не делать и эту задачу, в рамках озвученного бюджета на решение, не решать.

(0) приветствую. тоже есть похожая задачка для УПП: в моём случае пока не известно, надо ли соблюдать идентичность конфигураций или нет, но обмен данными точно будет неполным в одну сторону - одна база полная, вторая "не очень".

(26) "во второй базе иметь только белые операции" - как делали?

(26) да, и сделать РИБ... дело в том, что в типовой БП есть готовый РИБ по Организации, но его надо восстанавливать, т.к. в нем доработки сломали работу без ошибок.

и восстановление типового РИБ ПоОрганизации слишком трудоемко (не вписывается в бюджет), но не это страшно - поверх всего этого должно периодически делаться обновление типовыми решениями, после чего РИБ этот каждый раз придется реанимировать, хоть чуть-чуть, но придется

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

(32) Просто я надеялся на существование варианта, при котором писать вообще не придется или самый минимум.

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


Может использовать типовой план обмена "По организации", только нужно как-то отфильтровывать данные о конфигурации ...

Честно говоря с обменами работал только с РИБ

(34) В управленческую базу добавить план обмена - не проблема, а при варианте (32) он и нужен только в управленческой.

Есть тупой вариант - делаем копию рабочей базы, потом в ней убиваем все нетиповые документы / движения обработкой ...

Да конфа будет нетиповая, но какая разница - данных-то не будет лишних

(35) Его придется допиливать в базе - источнике при каждом обновлении типовой

(36) это при условии, что в этой убиваемой копии не будет ссылочной целостности с доработками. Рассмотрите, например, БП+БФ в качестве готового примера того, как типовая превратилась в нетиповую, по сути. В ней есть план обмена ПоОрганизации (а это как раз РИБ и есть) - но с ним сейчас невозможно работать - в существующем сейчас виде он неработоспособен.

(36) Я думал над вариантом сделать копию и накатить типовой cf - но малину портят документы по упр. организации, удалять которые будет слишком долго за много лет.
(37) Только при добавлении новых метаданных, да. Неувязочка, не универсально получается ((

Выходит, живой вариант (без поддержки) - только бредовариант №1 из стартового поста.

(39) Использовать вариант из (34)

(40) тогда нарушается исходное условие задачи "раз и навсегда".

Добра всем.

Задачу решил-таки при помощи штатных средств + немного кода. Низкий поклон Garykom за наводку и разъяснения.

В итоге задействовал штатный план обмена "Полный", использую для отслеживания изменений + учет сообщений между узлами. А само формирование файла - минимум кода благодаря сериализации, просто и эффективно. Немного заморочек пришлось решить только для отсечения данных по управленческой организации кодом.

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

Еще раз спасибо всем за советы.