жили были с одной базой 1С, в которой велось несколько организаций и сводная аналитическая отчетность замечательно формировалась отчетами на СКД из единой базы

прилетела задача от руководства: базы разъединить - для каждой организации отдельная база, и все - вопрос дальше однозначно не обсуждается, но нужна сводная отчетность

---------------------------- ОТСТУПЛЕНИЕ BEG
метода доработки РУКАМИ одного конкретного существующего отчета СКД для получения той же сводной аналитики опробована:
- добавляем в наборы данных "набор данных - объект" и указываем его поля
- руками же добавляем табличную часть "отчета-объекта" (в том самом окне где кнопка "Открыть схему компоновки данных" ), в нее сопоставляем соответствующее количество реквизитов
- на вкладке связей досвязываем эти внешние данные
- в ПриКомпоновкеДанных через СОМ-объект V8x.Application коннектимся к базе, выполняем запрос на "удаленной" базе, прогружаем результат в табличную часть
- процессор инициализируем с "внешними данными" компонуем и вуаля - отчет готов, работает!!!
----------------------------- ОТСТУПЛЕНИЕ END

не хочется почти сотню отчетов руками переводить на эти рельсы, а написать что-то более-менее универсальное для работы с 2-мя базами

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

ВОПРОС 1: с технической точки зрения есть ли возможность ПРОГРАММНО добавить в схему компоновки необходимое количество "копий" оригинальных наборов (работающих с одной базой), так чтобы эти копии были полноценными "наборами-объектами" с теми же полями и им ПРОГРАММНО подобавлять табличные части "отчета-объекта" с необходимыми реквизитами ?

ВОПРОС 2: есть ли возможность ПРОГРАММНО добавить новую связь на вкладку "связи наборов данных" ?

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

(1) и сколько денег и времени на внедрение надо будет вбухать на эту консолидацию ?

(2) много. но точечно скомуниздить подход ничего не мешает.

(1) если предположить, что конфы 2 баз абсолютно одинаковые, плюс через план обмена добиваемся "синхронизации" основных справочников (типа Номенклатура и все с ней связанные, Контрагенты и т.д.) только в одну сторону - из основной базы во 2-ю, во 2-ой запрет на заведение/редактирование

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

т.к. табдок вчистую не "просуммируешь" функциями СКД, прописанными в выражениях ресурсов

может что-то типа со 2-ой базы возвращать ЗначениеВСтрокуВнутр от РезультатаСкомпонованногоВ_ТЗ, а на стороне первой базы ЗначениеИзСтрокиВнутр ?

UP

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

(6) Внешние источники данных.

+(6) самый простой способ - это сделать РИБ из трех узлов: Центр, ФирмаА, ФирмаБ с обменом только между ПБ и ЦБ.

(7) это точно такое же кривое решение, как суета с отчетами из(0)

(0) А потом вспомнят что лет 5 назад была еще база(с другой конфигурацией) и потребуют что бы отчет и ее данные обрабатывал. Тогда и (8) не поможет

(9) пустой разговор.

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

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

(11) а зачем выпускать ЦБ из облака? Не выпускайте. Какая религия мешает и ЦБ, и ПБ в облаке хранить?

что так же мешает ПБ разнести на эти ваши сервера, а ЦБ продолжать хранить в облаке?

какя-то у вас там секта деструктивная...

(0) нафиг тебе табличная часть?

По поводу программного добавления - не проблема:
        ИсточникДанных = СхемаКомпоновкиДанных.ИсточникиДанных.Добавить();
    ИсточникДанных.Имя = "ИсточникДанных1";
    ИсточникДанных.ТипИсточникаДанных = "Local";

    НаборДанных = СхемаКомпоновкиДанных.НаборыДанных.Добавить(Тип("НаборДанныхЗапросСхемыКомпоновкиДанных"));
    НаборДанных.Имя = "НаборДанных1";
    НаборДанных.ИсточникДанных = ИсточникДанных.Имя;
    НаборДанных.ИмяОбъекта = "Таб";

(8) Вот еще геморой с обменами поиметь

Если ТС устраивает срез отчетности получаемый таким образом, то в чем проблема? Нафиг строить консолидацию, обмены и прочий геморой если надо получить тупо один-два отчета?

(18)>> если надо получить тупо один-два отчета?
(0) >> не хочется почти сотню отчетов руками переводить на эти рельсы,

один-два - это сотня?

(15) судя по вопросу правильно ли делаю вывод что в коде

ВнешниеНаборыДанных = новый Структура;
ВнешниеНаборыДанных.Вставить("ВнешнийНабор", ТабличнаяЧасть);
ПроцессорКомпоновкиДанных.Инициализировать(МакетКомпоновки, ВнешниеНаборыДанных, ДанныеРасшифровки, Истина);

в качестве ТабличнаяЧасть может выступать не то что "натыкано" в конфигураторе мышой на форме с указанием типа конкретного реквизита, а вообще любая ТЗшка ?

Простой вопрос к ТС:
в вашей общей базе есть контрагент А. Базы разъехались, стало 2 контрагента А. В первой базе, зачем-то контрагента А изменили (поменялась ссылка, инн или любое другое поле синхронизации). Есть какие-то отчеты, которые как-то анализируют контрагентов. Соответственно, в результате отчет покажет видимо не то, что ожидалось. Аналогично с номенклатурой. Даже если везде установлена синхронизация по ссылке, ничто не мешает, кому-то взять и контрагента А перебить в ниндендо Б.

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

Все правильно сказано в (10). Добавить нечего.

(20) ПроцессорКомпоновкиДанных.Инициализировать(МакетКомпоновки,Новый Структура("Таб", Таб), ДанныеРасшифровки);
Таб - таблица значений

(21) читай внимательно (4) про запреты во второй базе

(24) я это читал :)

(4) А что делать если филиалу надо завести нового контрагента или номенклатуру? Звонить в центр и ждать обмена?

А что кстати в отчетах? Откуда там данные с запросов? С регистров каких-то?

(26) за (23) сэнкс, попробую
ассортимент всегда сначала появляется в первой конторе, если товар ходовой тогда спустя время закупается и на вторую, разлет по времени - недели и больше
с контрагентами все еще проще, пересечений нет - разные сегменты рынка

(0)  1. Внешние источники данных.
     2. Если скуль - линкованый сервер рулит. (строка,число,дата)

(27) со справочников и с регистров, в основном классика жанра - взаиморасчеты, продажи, партии, остатки

(29) >>1. Внешние источники данных.
Что подразумеваешь ? Это ODBC или СКД-шный механизм ?

>> 2. Если скуль - линкованый сервер рулит. (строка,число,дата)
MS SQL 2008, но вот про линкованность сервера малограмотен (пока :), можешь чуть шире пояснить?

(29) с внешними источниками ты себе больше проблем огребешь с этими сопоставлениями названий реквизитов

(0) еще в 2009г выбрал метод описанный в отступлении. Работает до сих пор. Все что хочет автор добиться тогда не удалось, а переделывать потом уже не сложилось) базы абсолютно разные. пользователи разные.
Например прототип отчета создается в конфигураторе и там же прописываются поля. любые его варианты добивают пользователи.
из неприятных моментов, который преследует этот метод в работе это первичное ожидание коннекта по сом. последующие вызовы быстрее.
В моем случае было проще. Не было необходимости в переводе тысяч отчетов на новые рельсы. Все отчеты писались с нуля.