Добрый день.
Есть база УПП с ведением регламентного учета N организаций.
К примеру, Организация1, Организация2, Организация3
Стоит задача консолидировать данные в рамках использования УПП на ОрганизацияОбщая. В ТУ ЖЕ БАЗУ.

Т.е. документы по Организация1, Организация2, Организация3 должны "клонироваться" для ОрганизацияОбщая.

Мое видение было - регистрация документов для обмена только по Организация1, Организация2, Организация3, обмен по правилам обмена.

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

Вопрос. Кто-нибудь сталкивался с обменом базы в саму же себя?
Можно это решить пользовательскими настройками или придется перепахивать обработку ОбменДаннымиXML, модуль Процедуры обмена данными?

Конфа "Управление производственным предприятием для Украины", редакция 1.3
Разработка конфигурации: "ABBYY Ukraine", 2005-2013 (1.3.24.5)

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

Кхм... Этот узел сменять перед выгрузкой/загрузкой (там кажется код - ключевой значение имеет) - так пробовали?

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

(0) ужас. Ты представляешь, что будет в базе твориться? Ну ладно контрагенты, номенклатура и т.д., база та же - значит все элементы найдутс по гуидам, но нумерация документов! Она то сквозная. Да и засрете вы ее такими темпами

Уж если консолидировать, то в такой же по конфигурации базе, но в отдельной.

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

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

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

В два раза раздуется из-за движений, и разделитель будет с названием Общая организация... Или, есть подозрение, что итоги пухнуть будут из-за различий в списаниях?

(0) Можно в общих чертах зачем так делать?Не проще написать/переписать нужный отчет? Я еще понимаю трансформация данных. А топорно копировать - это очень оригинально.

(0) Что значит "консолидировать данные ..."?

Все данные по организациям уже в одной базе.
Делайте сводные отчеты по всем организациям.

(7) (8) Отчёты (а их множество) переделывать дороже, чем нагрузить сервер. А партионное списание - ещё убийственней.

(9) про там множество, переделывать дороже. Очень спорно. Если вообще переделывать надо.
А вот тот же справочник Сотрудники и  весь учет ЗП не плохо покушает голову тому кто будет делать обмен :)) Кстати то же партионное списание. Нет, сделать конечно можно что угодно. Вопрос только один. Фейхуа?
Но интересен ответ от автора. Ради каких отчетов сыр бор. Про УПП Украина не скажу. Но вот УСО которое на базе УПП. Я бы так  корежить не стал.

Хм... про Сотрудников - хорошее замечание...

(to all) Задача ставилась не мной...
Это один из предложенных вариантов т.н. упр. учета и консолидации. Его продавливают бухгалтера, типа так им проще.
Насчет дублирования записей согласен - не айс. Но можно подходить с умом. По плану обмена выгружаются лишь те документы, которые участвуют в регламентном учете. Вариант не супер, было предложено 6-7 вариантов, в т.ч. покупка того же ИТАН для целей конслидации. Так что пока прорабатываем САБЖ.

(5) Насчет регистров, где нет измерения - Организации - не думал. Дельная мысль. Если, конечно, эти регистры там используют, надо уточнить. Если используют, тогда от методики придется отказаться, т.к. будет задвоение данных.

(7) (8) (9) Отчеты переписать не так сложно. Найти способ указывать "Организация в ИЕРАРХИИ (&Организации)" или что-то вроде того.
Думали и на эту тему.
Это не решит проблему, т.к. в общем виде нужен управленческий баланс по группе организаций. С закрытием финансовых результатов, со своим расчетом себестоимости, со своим учетом товаров/касс и т.п.

(7) Не "Топорно копировать". Именно трансформировать. Перечень документов, поля поиска объектов и нумерация пока еще определяются. Документы переносятся с движениями. Что еще. Договоры, подразделения организаций создаются для консолидирующей организации по тем же правилам обмена, писанными в конвертации.

(10) А в чем проблема с сотрудниками? То, что их тоже будут дубли? Можно складывать в отдельную группу, делов-то). В расчете ЗП тоже пока проблем не вижу. Коллеги, поделитесь опытом, какие могут быть подводные камни с учетом ЗП?

"Можно складывать в отдельную группу, делов-то" - сорри, даже в диалог вступать нет желания.

Сотрудник, который работает по основному месту работы в организации "А" и внешним совместителем в организации "Б" куда складывать будешь?

Как выкручиваться будешь с НДФЛ сотрудников, которые конфигурация "складывает" по физическим лицам?

Имхо, уж если есть дикое желание что-то "складывать", то "складывай" отражение зарплаты в регламентном учете, но не саму зарплату.

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

(0) А зачем в ту же? Сделай в соседнюю

(14) Просил поделится опытом. Не разводить холивар. За наводку про НДФЛ - спасибо. Про внешних сотрудников - тоже буду думать.
Хотя, если рассматривать вариант запрета редактирования документов, перенесенных обменом, и перенос движений вместе с самим документом, то проблема расчета ЗП как-то отпадает.
Доначисления - отдельными документами.
Регламента расчета НДФЛ и взносов ЕСВ там не будет)))

(15) (16) Бухи хотят видеть "Документ-Источник".
В случае 2-х баз ссылку на "породивший документ" мы не получим.
Можно, конечно, выгружать по 2-м планам обмена, первый - один в один, второй - по описанному сабжу, но зачем тогда 2-я база?

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