Доброе утро, коллеги. Есть две идентичные базы Комплексной автоматизации, без доработок (на разные организации холдинга). Руководство в целях получения финансовых результатов по всему холдингу предлагает поставить третью КА, и туда передавать данные из этих двух. Собственно, хотел посоветоваться. Принять этот вариант, или настоять на том, что бы обе организации велись в одной базе? В случае одной базы данные из второй все равно перетаскивать. Плюс одна организация более "закрытая", рядовые пользователи второй не должны видеть, что там в первой. Думал, может сделать распределенную базу? Насчет переноса данных, как я понял, делать через конвертацию данных и долго курить правила. Или есть другие варианты? Подскажите.

(0) Сам будешь делать всю эту  кухню?

(1) Да, сам.

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

Если пишешь, что базы идентичные полностью в плане конфигурации поставщика.

(3) Времени немного. Две недели. С учетом того, что КА впервые вижу, так совсем мало

Существенный вопрос в том как они зарождались, независимо или одна родила другую

Как вариант, думал только проводки перетащить через ОЛЕ

Возьми одну из баз. Надо будет решить для себя, что какая-то из баз будет главной.

Выдели из нее переферийный узел с РИБ по Организации. Можно даже создать этот узел. А можно и не создавать первичный образ этого узла.

Затем выгрузи из этого центрального конфигурацию в файл. Загрузи в новый как бы периферийный конфу из файла. И привяжи ее к главному узлу. Затем обменами всего и вся периферийка потечет в главный узел.

(5) Независимо. Одна фирма прям начата в КА, вторая переносом данных из старой программы

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

И да. Самый существенный вопрос в том, откуда взялась вторая база.

Если у второй базы по всем предопределенным элементам, объектам разным пойдут УИД-ы свои собственные, то соединить их через РИБ не получится.

(9) рецепты "слей в одну" есть у тебя?

(8) проблема такая, что для разных баз должна быть общая база НСИ. Ну если условно так выразиться. Там не просто нормативно-справочная информация, а вообще, вся системно/платформенная инфа должна быть одинаковая.

(12) Допустим, 1-я орг. главная. Сделать через РИБ вторую, там будет НСИ как в первой. Очистить базу. Из второй выгрузить и загрузить их в "новую" вторую? Взлетит?

(13) из второй выгрузить и загрузить данные. Через "конвертацию"

(11) Для каждого конкретного случая рецепт свой. Автоматом конечно никак нужно или правила через КД писать или другим методом перекинуть документы с сопоставлением НСИ

(14) Ну да. С учетом того, что вторая база рождалась из старой базы, то без "конвертации" не обойтись.

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

(14) Если предположить, что у холдинга это не единственная такая база вторая, а есть какие-то еще базы... Может быть пойти по пути разработки центральной базы холдинга с настройкой-разработкой комплектов КД-правил, что для первой базы, что для второй, что для остальных последующих.

Просто писать и ставить обмены между базами отдельных Организаций с Холдингом в Центральной базе.

А если по ОЛЕ только проводки перетащить, в комплексной не соберутся отчеты, я думаю? Баланс там, ДДС и прочее, что финдиру нужно,

(19) А смысл тащить все док-ты?
Уже июнь - док-тов, наверняка, не сотня, а намного больше. Придется перепроводить (всё, с начала года) и разгребать ошибки.
Учитывая, что базы велись параллельно: как будет с нумерацией док-ов? Ладно РТиУ, а СФ?
Моё предложение:
1. Слить справочники. Номенклатура, контрагенты - попроще будет. Статьи затрат и пр. бухгалтерская фигня - сложнее. Физлица, сотрудники - вопрос (если сотрудники есть там и там - пипец).
2. Остатки (номенклатура, расчеты и пр.) на середину года. Хотя, конечно, лучше на начало - если вариант - ждать начала след. года.
3. И все равно, косяк с док-ами (за июнь).

(20) Sorry, если в каждой базе только одна организация - то проблем с нумерацией документов - не будет. Нужно внести префиксы организация и перенумеровать документы (без перепроведения). НСИ из двух баз сливается с возникновением дубликатов. Муторно, но технология поиска и устранения дубликатов НСИ худо/бедно разработана.

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

До сих пор эти тупорылые фин директора никак не могу понять, что 1С это не эксэлеь, там нельзя "2 Таблички " просто так свести

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

И у него есть две базы, которые уже используют КА 2

Мысль такая : в КА 2 есть инструменты бизнес-планирования или бюджетирования. Управленческую инфу по холдингу нужно консолидировать именно в них.

(23) +100500

(22) он, том самый общий РИБ для получения ЦБ - эта база ЦБ == управленческий баланс. Поставьте задачу методически грамотно и будете решать ее совсем другими способами.

Имхо: на этапе внедрения, ЦБ создается из копии первой автономной базы ("первая" - предположительно так, у которой наиболее полная НСИ); все три базы "связываются" в РИБ настройками узлов обмена; в другой (второй) бывшей автономной базе регистрируются изменения НСИ и передаются в центральную базу; далее регистрация изменений документов с передачей; потом регистрация и передача регистров и т.п. и т.д... Т.е. в ЦБ к данным первой базы сливаются данные второй базы. Можно сразу, можно поэтапно - всё зависит от объёма данных. После этого в ЦБ следует долгий период устранения дублей НСИ и передача этих изменений в подчиненные базы. Таким образом "синхронизируется" НСИ. Процесс "синхронизации" контролируется отчетами (например получением баланса организаций)...как то вот так.

+(26) Может проще просто дернуть из одной базы в другую данные для построения отчета консолидированного по http.

(28) кому-то может и проще.
Задачу на консолидированные отчеты поставить и все.

(0) Тебе надо решить ключевую задачу перед сливанием баз.

Разобраться с тем уникальные ли у тебя справочники в этих базах или нет.

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

То есть при сливании баз ты получишь не 2 элемента справочника а 1.

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

(28) "проще просто дернуть из одной базы в другую данные для построения отчета консолидированного"

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

Варианты решения.

1. Создается сводная база. Куда заливаются данные из трех баз. В этом случае все шикарно работает. Основная проблема решить вопрос уникальности НСИ и слить справочники.

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

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

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

(30) Все это после слияния решается удаление дублей, там всего то надо пройтись по контрагентам и по номенклатуре

(33) но на практике можно на дубли даже не заморачиваться.

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

Ну будут в Центре дубли... Для построения отчетов это не самая большая проблема.

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

(33) Удаление дублей это если у тебя в базах НСИ велись отдельно.

Но если в одну из баз у тебя часть НСИ заливалась из другой то при сливании НСИ у тебя произойдет затирание.

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

А теперь ты хочешь слить справочники.

Берешь первую базу с 1000 контрагентов и переливаешь в нее 200 контрагентов из другой базы. При заливании они находят по ГУИД своих предшественников и затирают.

(34) Я вот тоже к этому склоняюсь. По крайней мере, быстро станет ясно, что не взлетело. А если не взлетит, тогда уже с дублями заморачиваться.

(34) "обратно ничего не передаем"

Если обратно ничего переливать не нужно это вообще простая задача.
Настроили план обмена и вообще пофиг на то что дубли могут затереть друг друга.

Но начальство обычно ставит задачи сложнее.

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

И вишенка на тортике - в сводную базу будут переводиться пользователи по одному.

(35) Не, базы отдельно родились. Каждая из своей коробки.

(37) Больше волнует дублирование всяких справочников, типа движение денежных средств, и прочие, который при первом запуске создаются

(39) Там само наличие консолидированной отчетности смотри. Вполне вероятно, что проблема с дублями решится некритично.

А то будет вас там колбасить на слияние баз, но отчетность нужную так и не получите.

И нафига козе баян, икона папуасу?! Это я про отчеты боссу

Мой путь был бы таким.
1. Слил базы в одну.
2. Поднял РИБ по организации.
3. Поддерживал 3 базы: центральная - для отчётности, периферийные - для работы.

Точно, не "схлопнутся" они в ЦБ. Будет выручка от "торговли унитазами" в одной базе и от "торговли унитазами" в другой. А на сколько унитазов продали, финдир так и не увидит

(0) я бы написал обмен на уровне бюджетов и не парился бы

(42) "Будет выручка от "торговли унитазами" в одной базе и от "торговли унитазами" в другой"

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

(42) То есть грузишь пакет от периферийной базы.

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

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

(45) Фактически, по трудозатратам получается столько же, сколько перелить все данные и вычистить дубли. А может и больше. Верно?

(46)Такой способ выглядит привлекательней. Один раз разгрёб и всё.

(46) Тебе все равно нужны правила для построения консолидированного отчета.
Даже если бы изначально база уже держала бы все нужные тебе Организации, то без обработки напильником именно нужная боссу отчетность фиг бы получилась "из коробки".

Придумаешь в сводной базе настройку для отчетности, которая не будет заменять и перезаписывать дубли, а будет сразу по спискам номенклатуры работать. Ну как вариант.

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

(48) Почему? Открываешь любой стандартный отчет, и ставишь в настройках галочки по двум организациям - и данные выводятся общие. Или я не прав? КА я не знаю.

(46) Зачем тебе дубли вычищать ?

У тебя постановка задачи от начальства - например контрагент с определенным ИНН должен присутствовать в отчетах один раз.

Ты берешь и во всех данных наборов записей по регистрам проверяешь есть ли у тебя дубли по измерению контрагент. Если есть заменяешь то что в наборе записей на того который считается основным.

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

(50) Он тебе про исключение внутригрупповых оборотов

(47) "Один раз разгрёб и всё."

А кто будет принимать решение какого контрагента убирать а какого оставлять ?

(52) Первый раз слышу, наверно я дикий. Что это за зверь?

(54) Все нужные отчеты раздельно. В разных базах. Сложи их в файлах экселя в нужный для босса отчет. Если при сложении не возникнет исключения внутренних оборотов ваше Холдинга, то тебе крупно повезло.

(55) Понял! Обороты между этими 2 организациями.

Между нашими двумя организациями

(53)Без разницы. Контрагент-то один и тот же.
Кстати, иногда при синхронизации происходит автоматическое сопоставление. Так что при слиянии может быть не так и много дублей.
Пробовать надо, однако.

(58) "Контрагент-то один и тот же."

Самый простой пример.

Две базы. Два списка контрагентов.

В одной базе у контрагента стоит признак "неплательщик" и "стопотгрузка".
В другой базе у этого же контрагента нет.

Если сливать НСИ только для получения отчетов тогда все равно с какими условиями останется контрагент.

А если из сводной базы будут документы выписывать то не все равно.

(59) пардонте за оффтоп , нефть-то ниже 42$ / баррель , поторопился с бравурной статьей ваш диванный аналитик ;)

(59)Думается, что данные признаки должны быть у договоров, а не у контрагентов. А договоры относятся к организации.

(61) Ну в контрагентах куча других реквизитов. Например типы цен (которые могут быт привязаны как к договорам так и контрагентам).

(62)Типы цен скорей всего имеют привязку к организации. Поскольку 1с РИБ по организации, то все такие нюансы уже учтены. Дубли при слиянии не исключены, но их нужно будет разгрести всего один раз. А дальше уже решать, вести ли обе организации в одной базе со всем юзверями, либо поднять РИБ и каждой организации поставить периферийную базу.

(41) "1. Слил бы базы в одну." Каким образом? Понятно, берем побольше и добавляем туда ту, что поменьше. Через КД?

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

(65) Так, допустим, привязал. Сделал обмен из второй периферийной в центральную. В центральной появились дубли. Отловил их, поменял в документах и справочниках из второй базы ссылки на элементы из первой. Теперь это надо передать обратно, и дубли появляются уже во второй периферийной, рабочей базе. Верно я мыслю?

(66) РС поменять не предлагать?

(67) Желательно оставить на поддержке, как есть.

(68) Как связаны содержимое РС и поддержка?

(69) Я думал, Вы предлагаете поменять какой-то регистр сведений.

(66) Конечно, мыслишь верно. А зачем тебе их обратно передавать? Какой в этом будет результат для работы операторов, менеджеров и т.п.?

Я же не зря выше неоднократно написал, что наличие центральной базы дает возможность построить центральную отчетность, но эту отчетность не нужно и не возможно передавать обратно в периферийную базу.

У тебя центральная база имеет узкую и весьма узкую цель - получение отчетности для босса.
Зачем ради этой цели ломать НСИ в периферийной базе?

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

Проводки не "сложатся"

(66)Обратно я бы образ выгрузил и не парился.

(74) Логично. Если в ЦБ все отловлено и все работает, образ обратно передать и все. Хорошо еще и тем, что т. к. компания работает 24/7, нужно будет всего на несколько часов закрывать доступ пользователей.

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

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

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

(72) А ты на что? Настрой получение отчетности. Или тебе кажется, что трах с дублями в обменах проще, чем отчет настроить на консолидацию по этим же дублям?

(78) вот именно! Это же нормальная работа так называемого "оперативного контура" :-)

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

Так, все, РИБ отпадает. После его создания закрытие месяца возможно только в центральной базе. Значит, из одной таскать данные через "выгрузку и загрузку", а из другой настраивать через КД. Наверно, лучше третью взять?

(82)Информация точно проверенная?

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

з.ы. Опять одна и та же трабла, что называют обмен РИБ, а на самом деле никакой РИБ не нужен, а нужен просто обмен.

Кстати, эта самая третья база :-)

Поскольку обе базы идентичные, то каждая исходная база - Центральная в плане обмена РИБ по Организации.
Дочерний узел ставим дочерним для обеих Центральных баз. И в него - в дочку от двух родителей - сливается инфа.

Буквально исполни поставленную задачу : // в целях получения финансовых результатов по всему холдингу предлагает поставить третью КА, и туда передавать данные из этих двух //

(83) Из описания конфигурации с сайта 1с.

(85) "Дочерний узел ставим дочерним для обеих Центральных баз. " - так можно?

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

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

Узел в списке узлов - это грубая идентификация.

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

Могут разные узлы ссылаться на физическом уровне на одну и туже базу? Конечно, ведь никаких способов контроля соответствия один-узел-одна-база нет.

Одна только оговорка. РИБ проверяет и подтверждает в обмене, что во всех узлах применена одинаковая конфигурация.
Если средствами самого РИБ синхронизацию конфигурации не делать, то нужно загружать ее из одинакового файла по всем базам узлов.

Но если пойти по пути решения самой задачи и ее самого простого варианта.

Нужен просто обмен данными. Не РИБ. Этому обмену данные надо создать/собрать/подложить и т.п.
Просто в новые правила еще одного обмена,
который решит проблему работы с базой в режиме "А вот она Я - база для консолидации и отчетов".

(31) нет. Если данные все загрузить в тз, а потом в типовом отчете на СКД использовать эту тз, там всё шикарно получается, и отборы, и группировки, и всё остальное. С расшифровками посложнее, но тоже решаемо.

(91) Как ты сделаешь расшифровку по номенклатуре или контрагентам если у тебя в ТЗ не элемент справочника а ссылка на данные ДРУГОЙ базы ?

Если у тебя данные из трех баз слиты в одну то конечно вопросов нет.

(88) Подскажи а как можно реализовать обмен между двумя базами но не через выгрузку - загрузку в файл а через подключение к базе ?

Да еще в ситуации когда РИБ не подходит - конфы разные.

При этом в конфе нет штатного механизма обмена через подключение (обычные формы).

Мне надо в сводную база залить 8 гигов данных. Чеерез фал это делать не хочется.

(93) Ну если обычные формы и даже если УФ, то все равно - это прямое подключение будет - это просто считай что подключение по COM - не самый быстрый вариант, но и прописывать надо будет точно также все по всем объектам. Или универсальное может есть где-то на основе метаданных (у меня такого нет)

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

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

(94) "Когда данных много, то обработка порциями -- источник пометил, выгрузил, Приемник получил и дальше погнал."

Это понятно.

Вопрос как сделать так чтобы выгрузка этих 8 гигов данных шла по схеме

1. Выгрузили порцию.
2. Загрузили порцию.

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

У меня между базами уже поднят другой план обмена где настроен обмен через файл. С периодичностью раз в 2 минуты. Но там мало данных передается.

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