Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Объединение двух баз КА

Объединение двух баз КА
Я
   Темный
 
30.06.20 - 11:15
Доброе утро, коллеги. Есть две идентичные базы Комплексной автоматизации, без доработок (на разные организации холдинга). Руководство в целях получения финансовых результатов по всему холдингу предлагает поставить третью КА, и туда передавать данные из этих двух. Собственно, хотел посоветоваться. Принять этот вариант, или настоять на том, что бы обе организации велись в одной базе? В случае одной базы данные из второй все равно перетаскивать. Плюс одна организация более "закрытая", рядовые пользователи второй не должны видеть, что там в первой. Думал, может сделать распределенную базу? Насчет переноса данных, как я понял, делать через конвертацию данных и долго курить правила. Или есть другие варианты? Подскажите.
   Фрэнки
 
1 - 30.06.20 - 11:17
(0) Сам будешь делать всю эту  кухню?
   Темный
 
2 - 30.06.20 - 11:18
(1) Да, сам.
   Фрэнки
 
3 - 30.06.20 - 11:19
Просто, если сам и временем располагаешь, что можно посоветовать ряд экспериментов провести, а затем уже примешь решение - получится или нет гарантий тут нет.

Если пишешь, что базы идентичные полностью в плане конфигурации поставщика.
   Темный
 
4 - 30.06.20 - 11:20
(3) Времени немного. Две недели. С учетом того, что КА впервые вижу, так совсем мало
   AAA
 
5 - 30.06.20 - 11:21
Существенный вопрос в том как они зарождались, независимо или одна родила другую
   Темный
 
6 - 30.06.20 - 11:22
Как вариант, думал только проводки перетащить через ОЛЕ
   Фрэнки
 
7 - 30.06.20 - 11:23
Возьми одну из баз. Надо будет решить для себя, что какая-то из баз будет главной.

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

Затем выгрузи из этого центрального конфигурацию в файл. Загрузи в новый как бы периферийный конфу из файла. И привяжи ее к главному узлу. Затем обменами всего и вся периферийка потечет в главный узел.
   Темный
 
8 - 30.06.20 - 11:23
(5) Независимо. Одна фирма прям начата в КА, вторая переносом данных из старой программы
   arsik
 
9 - 30.06.20 - 11:23
(0) Ну слей все в одну и сделай периферийную для обычных юзеров с фильтром по организации.
   Фрэнки
 
10 - 30.06.20 - 11:24
И да. Самый существенный вопрос в том, откуда взялась вторая база.

Если у второй базы по всем предопределенным элементам, объектам разным пойдут УИД-ы свои собственные, то соединить их через РИБ не получится.
   Фрэнки
 
11 - 30.06.20 - 11:25
(9) рецепты "слей в одну" есть у тебя?
   Фрэнки
 
12 - 30.06.20 - 11:28
(8) проблема такая, что для разных баз должна быть общая база НСИ. Ну если условно так выразиться. Там не просто нормативно-справочная информация, а вообще, вся системно/платформенная инфа должна быть одинаковая.
   Темный
 
13 - 30.06.20 - 11:32
(12) Допустим, 1-я орг. главная. Сделать через РИБ вторую, там будет НСИ как в первой. Очистить базу. Из второй выгрузить и загрузить их в "новую" вторую? Взлетит?
   Темный
 
14 - 30.06.20 - 11:33
(13) из второй выгрузить и загрузить данные. Через "конвертацию"
   arsik
 
15 - 30.06.20 - 11:34
(11) Для каждого конкретного случая рецепт свой. Автоматом конечно никак нужно или правила через КД писать или другим методом перекинуть документы с сопоставлением НСИ
   Фрэнки
 
16 - 30.06.20 - 11:35
(14) Ну да. С учетом того, что вторая база рождалась из старой базы, то без "конвертации" не обойтись.

Хотя есть риск, что возни будет много, а на выходе ничего не получится.
   Фрэнки
 
17 - 30.06.20 - 11:37
(14) Если предположить, что у холдинга это не единственная такая база вторая, а есть какие-то еще базы... Может быть пойти по пути разработки центральной базы холдинга с настройкой-разработкой комплектов КД-правил, что для первой базы, что для второй, что для остальных последующих.
   Фрэнки
 
18 - 30.06.20 - 11:39
Просто писать и ставить обмены между базами отдельных Организаций с Холдингом в Центральной базе.
   Темный
 
19 - 30.06.20 - 12:01
А если по ОЛЕ только проводки перетащить, в комплексной не соберутся отчеты, я думаю? Баланс там, ДДС и прочее, что финдиру нужно,
   Масянька
 
20 - 30.06.20 - 12:11
(19) А смысл тащить все док-ты?
Уже июнь - док-тов, наверняка, не сотня, а намного больше. Придется перепроводить (всё, с начала года) и разгребать ошибки.
Учитывая, что базы велись параллельно: как будет с нумерацией док-ов? Ладно РТиУ, а СФ?
Моё предложение:
1. Слить справочники. Номенклатура, контрагенты - попроще будет. Статьи затрат и пр. бухгалтерская фигня - сложнее. Физлица, сотрудники - вопрос (если сотрудники есть там и там - пипец).
2. Остатки (номенклатура, расчеты и пр.) на середину года. Хотя, конечно, лучше на начало - если вариант - ждать начала след. года.
3. И все равно, косяк с док-ами (за июнь).
   Serg_1960
 
21 - 30.06.20 - 12:20
(20) Sorry, если в каждой базе только одна организация - то проблем с нумерацией документов - не будет. Нужно внести префиксы организация и перенумеровать документы (без перепроведения). НСИ из двух баз сливается с возникновением дубликатов. Муторно, но технология поиска и устранения дубликатов НСИ худо/бедно разработана.
   Темный
 
22 - 30.06.20 - 12:24
(21) В принципе, если сделать схему ЦБ и две периферийных для каждой организации, и РИБ, то ЦБ может быть и кривой. Главное, что бы отчеты все формировались, данные туда можно вообще запретить вводить
   Kigo_Kigo
 
23 - 30.06.20 - 12:26
До сих пор эти тупорылые фин директора никак не могу понять, что 1С это не эксэлеь, там нельзя "2 Таблички " просто так свести
   Фрэнки
 
24 - 30.06.20 - 12:27
(22) на самом деле, если посмотреть на задачу немного шире, то диру не нужны все эти документы и дкументики, номенклатура и прочая ересь.

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

Мысль такая : в КА 2 есть инструменты бизнес-планирования или бюджетирования. Управленческую инфу по холдингу нужно консолидировать именно в них.
   Масянька
 
25 - 30.06.20 - 12:28
(23) +100500
   Фрэнки
 
26 - 30.06.20 - 12:29
(22) он, том самый общий РИБ для получения ЦБ - эта база ЦБ == управленческий баланс. Поставьте задачу методически грамотно и будете решать ее совсем другими способами.
   Serg_1960
 
27 - 30.06.20 - 12:44
Имхо: на этапе внедрения, ЦБ создается из копии первой автономной базы ("первая" - предположительно так, у которой наиболее полная НСИ); все три базы "связываются" в РИБ настройками узлов обмена; в другой (второй) бывшей автономной базе регистрируются изменения НСИ и передаются в центральную базу; далее регистрация изменений документов с передачей; потом регистрация и передача регистров и т.п. и т.д... Т.е. в ЦБ к данным первой базы сливаются данные второй базы. Можно сразу, можно поэтапно - всё зависит от объёма данных. После этого в ЦБ следует долгий период устранения дублей НСИ и передача этих изменений в подчиненные базы. Таким образом "синхронизируется" НСИ. Процесс "синхронизации" контролируется отчетами (например получением баланса организаций)...как то вот так.
   arsik
 
28 - 30.06.20 - 12:49
+(26) Может проще просто дернуть из одной базы в другую данные для построения отчета консолидированного по http.
   Фрэнки
 
29 - 30.06.20 - 12:56
(28) кому-то может и проще.
Задачу на консолидированные отчеты поставить и все.
   ЧессМастер
 
30 - 30.06.20 - 12:57
(0) Тебе надо решить ключевую задачу перед сливанием баз.

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

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

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

Не пойму зачем тебе нужны правила обмена. если конфигурации одинаковые все сливается прекрасно без правил обмена.
 
 Рекламное место пустует
   ЧессМастер
 
31 - 30.06.20 - 13:05
(28) "проще просто дернуть из одной базы в другую данные для построения отчета консолидированного"

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

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

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

2. Из одной базы вы дергаете данные из двух других баз (например по COM).
В этом случае у вас собрать данные не получится - данные которые вы по COM получите вам нужно будет добавлять к тем данным которые вы получили из базы где формируете отчет.
Но никаких возможностей типового отчета (фильтры, отборы, группировки) вы из этих данных не получите.
   ЧессМастер
 
32 - 30.06.20 - 13:07
(28) То есть при варианте "дернуть из одной базы в другую данные для построения отчета консолидированного" вы получите только самый простенький отчет с суммами.

Но построить отчет с фильтрами - отборами - группировками по контрагентам или номенклатуре при том что часть этих данных в одной базе а часть в другой не получится.
   Kigo_Kigo
 
33 - 30.06.20 - 13:24
(30) Все это после слияния решается удаление дублей, там всего то надо пройтись по контрагентам и по номенклатуре
   Фрэнки
 
34 - 30.06.20 - 13:33
(33) но на практике можно на дубли даже не заморачиваться.

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

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

Нужен эксперимент и тестирование. Выбираем центральную, цепляем периферийные к ней, сливаем в нее из периферийных, обратно ничего не передаем. И настраиваем в центральной получение отчетов для босса.
   ЧессМастер
 
35 - 30.06.20 - 13:34
(33) Удаление дублей это если у тебя в базах НСИ велись отдельно.

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

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

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

Берешь первую базу с 1000 контрагентов и переливаешь в нее 200 контрагентов из другой базы. При заливании они находят по ГУИД своих предшественников и затирают.
   Темный
 
36 - 30.06.20 - 13:40
(34) Я вот тоже к этому склоняюсь. По крайней мере, быстро станет ясно, что не взлетело. А если не взлетит, тогда уже с дублями заморачиваться.
   ЧессМастер
 
37 - 30.06.20 - 13:41
(34) "обратно ничего не передаем"

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

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

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

И вишенка на тортике - в сводную базу будут переводиться пользователи по одному.
   Темный
 
38 - 30.06.20 - 13:41
(35) Не, базы отдельно родились. Каждая из своей коробки.
   Темный
 
39 - 30.06.20 - 13:43
(37) Больше волнует дублирование всяких справочников, типа движение денежных средств, и прочие, который при первом запуске создаются
   Фрэнки
 
40 - 30.06.20 - 13:46
(39) Там само наличие консолидированной отчетности смотри. Вполне вероятно, что проблема с дублями решится некритично.

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

И нафига козе баян, икона папуасу?! Это я про отчеты боссу
   Креатив
 
41 - 30.06.20 - 13:47
Мой путь был бы таким.
1. Слил базы в одну.
2. Поднял РИБ по организации.
3. Поддерживал 3 базы: центральная - для отчётности, периферийные - для работы.
   Темный
 
42 - 30.06.20 - 13:50
Точно, не "схлопнутся" они в ЦБ. Будет выручка от "торговли унитазами" в одной базе и от "торговли унитазами" в другой. А на сколько унитазов продали, финдир так и не увидит
   HeKrendel
 
43 - 30.06.20 - 13:58
(0) я бы написал обмен на уровне бюджетов и не парился бы
   ЧессМастер
 
44 - 30.06.20 - 13:59
(42) "Будет выручка от "торговли унитазами" в одной базе и от "торговли унитазами" в другой"

Тебе никто не мешает при получении пакета обмена от периферийной базы искать дубли и заменять ссылки в загружаемом наборе.
   ЧессМастер
 
45 - 30.06.20 - 14:01
(42) То есть грузишь пакет от периферийной базы.

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

В результате ты легко можешь подставить как в документы так и в наборы записей регистров основные значения НСИ.
   Темный
 
46 - 30.06.20 - 14:05
(45) Фактически, по трудозатратам получается столько же, сколько перелить все данные и вычистить дубли. А может и больше. Верно?
   Креатив
 
47 - 30.06.20 - 14:08
(46)Такой способ выглядит привлекательней. Один раз разгрёб и всё.
   Фрэнки
 
48 - 30.06.20 - 14:18
(46) Тебе все равно нужны правила для построения консолидированного отчета.
Даже если бы изначально база уже держала бы все нужные тебе Организации, то без обработки напильником именно нужная боссу отчетность фиг бы получилась "из коробки".
   Фрэнки
 
49 - 30.06.20 - 14:24
Придумаешь в сводной базе настройку для отчетности, которая не будет заменять и перезаписывать дубли, а будет сразу по спискам номенклатуры работать. Ну как вариант.

Внутри бюджетирования такая задача решается. Дубли номенклатуры они же не только из разных баз возникают. Иногда без дублирования элементов просто не обойтись. Хоть всегда и клянут это все дело и проклинают, но все равно.
   Темный
 
50 - 30.06.20 - 14:28
(48) Почему? Открываешь любой стандартный отчет, и ставишь в настройках галочки по двум организациям - и данные выводятся общие. Или я не прав? КА я не знаю.
   ЧессМастер
 
51 - 30.06.20 - 14:36
(46) Зачем тебе дубли вычищать ?

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

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

И тебе будет все равно сколько времени люди которые ведут справочники будут избавляться от этих дублей.
   Krendel
 
52 - 30.06.20 - 14:36
(50) Он тебе про исключение внутригрупповых оборотов
   ЧессМастер
 
53 - 30.06.20 - 14:37
(47) "Один раз разгрёб и всё."

А кто будет принимать решение какого контрагента убирать а какого оставлять ?
   Темный
 
54 - 30.06.20 - 14:40
(52) Первый раз слышу, наверно я дикий. Что это за зверь?
   Фрэнки
 
55 - 30.06.20 - 14:45
(54) Все нужные отчеты раздельно. В разных базах. Сложи их в файлах экселя в нужный для босса отчет. Если при сложении не возникнет исключения внутренних оборотов ваше Холдинга, то тебе крупно повезло.
   Темный
 
56 - 30.06.20 - 14:49
(55) Понял! Обороты между этими 2 организациями.
   Темный
 
57 - 30.06.20 - 14:49
Между нашими двумя организациями
   Креатив
 
58 - 30.06.20 - 15:33
(53)Без разницы. Контрагент-то один и тот же.
Кстати, иногда при синхронизации происходит автоматическое сопоставление. Так что при слиянии может быть не так и много дублей.
Пробовать надо, однако.
   ЧессМастер
 
59 - 30.06.20 - 16:22
(58) "Контрагент-то один и тот же."

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

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

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

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

А если из сводной базы будут документы выписывать то не все равно.
   ChMikle
 
60 - 30.06.20 - 16:25
(59) пардонте за оффтоп , нефть-то ниже 42$ / баррель , поторопился с бравурной статьей ваш диванный аналитик ;)
 
 Рекламное место пустует
   Креатив
 
61 - 30.06.20 - 16:35
(59)Думается, что данные признаки должны быть у договоров, а не у контрагентов. А договоры относятся к организации.
   ЧессМастер
 
62 - 30.06.20 - 17:09
(61) Ну в контрагентах куча других реквизитов. Например типы цен (которые могут быт привязаны как к договорам так и контрагентам).
   Креатив
 
63 - 30.06.20 - 20:00
(62)Типы цен скорей всего имеют привязку к организации. Поскольку 1с РИБ по организации, то все такие нюансы уже учтены. Дубли при слиянии не исключены, но их нужно будет разгрести всего один раз. А дальше уже решать, вести ли обе организации в одной базе со всем юзверями, либо поднять РИБ и каждой организации поставить периферийную базу.
   Темный
 
64 - 02.07.20 - 09:27
(41) "1. Слил бы базы в одну." Каким образом? Понятно, берем побольше и добавляем туда ту, что поменьше. Через КД?
   Креатив
 
65 - 02.07.20 - 09:33
(64)Я бы попробовал меньшую привязать к большей в качестве периферийного узла.
   Темный
 
66 - 02.07.20 - 09:39
(65) Так, допустим, привязал. Сделал обмен из второй периферийной в центральную. В центральной появились дубли. Отловил их, поменял в документах и справочниках из второй базы ссылки на элементы из первой. Теперь это надо передать обратно, и дубли появляются уже во второй периферийной, рабочей базе. Верно я мыслю?
   ДенисЧ
 
67 - 02.07.20 - 09:40
(66) РС поменять не предлагать?
   Темный
 
68 - 02.07.20 - 09:40
(67) Желательно оставить на поддержке, как есть.
   ДенисЧ
 
69 - 02.07.20 - 09:42
(68) Как связаны содержимое РС и поддержка?
   Темный
 
70 - 02.07.20 - 09:44
(69) Я думал, Вы предлагаете поменять какой-то регистр сведений.
   Фрэнки
 
71 - 02.07.20 - 09:45
(66) Конечно, мыслишь верно. А зачем тебе их обратно передавать? Какой в этом будет результат для работы операторов, менеджеров и т.п.?

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

У тебя центральная база имеет узкую и весьма узкую цель - получение отчетности для босса.
Зачем ради этой цели ломать НСИ в периферийной базе?
   Темный
 
72 - 02.07.20 - 09:48
(71) У босса будет две строки с выручкой по одному виду деятельности, то же с филиалами, их вместо 20 - 40 станет, по затратам и т .д.
   Темный
 
73 - 02.07.20 - 09:48
Проводки не "сложатся"
   Креатив
 
74 - 02.07.20 - 09:51
(66)Обратно я бы образ выгрузил и не парился.
   Темный
 
75 - 02.07.20 - 09:53
(74) Логично. Если в ЦБ все отловлено и все работает, образ обратно передать и все. Хорошо еще и тем, что т. к. компания работает 24/7, нужно будет всего на несколько часов закрывать доступ пользователей.
   Креатив
 
76 - 02.07.20 - 10:00
(75)В таком случае тебе сначала на кроликах обязательно потренироваться, чтобы с рабочими базами уже по готовому сценарию делать.
   Темный
 
77 - 02.07.20 - 10:02
(76) Например выгрузить образ в новую базу, и дать людям в ней все проверить.
   Темный
 
78 - 02.07.20 - 10:49
(74) Ан нет, не получится так. Пока я буду с дублями разбираться, они в рабочей новых документов и прочего насоздают.
   Фрэнки
 
79 - 02.07.20 - 10:49
(72) А ты на что? Настрой получение отчетности. Или тебе кажется, что трах с дублями в обменах проще, чем отчет настроить на консолидацию по этим же дублям?
   Фрэнки
 
80 - 02.07.20 - 10:50
(78) вот именно! Это же нормальная работа так называемого "оперативного контура" :-)
   Креатив
 
81 - 02.07.20 - 11:23
(77)Взять копии баз, слить их, написав себе инструкцию. Кстати, если заморочиться, то после настройки синхронизации, но перед слиянием закинуть в базы публичные идентификаторы, возможно тогда дублей не будет.
   Темный
 
82 - 02.07.20 - 12:10
Так, все, РИБ отпадает. После его создания закрытие месяца возможно только в центральной базе. Значит, из одной таскать данные через "выгрузку и загрузку", а из другой настраивать через КД. Наверно, лучше третью взять?
   Креатив
 
83 - 02.07.20 - 13:51
(82)Информация точно проверенная?
   Фрэнки
 
84 - 02.07.20 - 14:32
(82) кто тебе мешает оторвать этот самый РИБ от центральной, чтоб он был в каждой базе сам по себе?
Обмен все равно идет только в одну сторону.

з.ы. Опять одна и та же трабла, что называют обмен РИБ, а на самом деле никакой РИБ не нужен, а нужен просто обмен.
   Фрэнки
 
85 - 02.07.20 - 14:36
Кстати, эта самая третья база :-)

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

Буквально исполни поставленную задачу : // в целях получения финансовых результатов по всему холдингу предлагает поставить третью КА, и туда передавать данные из этих двух //
   Темный
 
86 - 02.07.20 - 15:08
(83) Из описания конфигурации с сайта 1с.
   Темный
 
87 - 02.07.20 - 15:10
(85) "Дочерний узел ставим дочерним для обеих Центральных баз. " - так можно?
   Фрэнки
 
88 - 05.07.20 - 10:00
(87) Так ведь каждая из Центральных баз не сможет догадаться, что этот узел для нее дочерний.

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

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

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

Могут разные узлы ссылаться на физическом уровне на одну и туже базу? Конечно, ведь никаких способов контроля соответствия один-узел-одна-база нет.
   Фрэнки
 
89 - 05.07.20 - 10:03
Одна только оговорка. РИБ проверяет и подтверждает в обмене, что во всех узлах применена одинаковая конфигурация.
Если средствами самого РИБ синхронизацию конфигурации не делать, то нужно загружать ее из одинакового файла по всем базам узлов.
   Фрэнки
 
90 - 05.07.20 - 10:10
Но если пойти по пути решения самой задачи и ее самого простого варианта.

Нужен просто обмен данными. Не РИБ. Этому обмену данные надо создать/собрать/подложить и т.п.
Просто в новые правила еще одного обмена,
который решит проблему работы с базой в режиме "А вот она Я - база для консолидации и отчетов".
   hhhh
 
91 - 05.07.20 - 10:16
(31) нет. Если данные все загрузить в тз, а потом в типовом отчете на СКД использовать эту тз, там всё шикарно получается, и отборы, и группировки, и всё остальное. С расшифровками посложнее, но тоже решаемо.
   ЧессМастер
 
92 - 17.07.20 - 17:06
(91) Как ты сделаешь расшифровку по номенклатуре или контрагентам если у тебя в ТЗ не элемент справочника а ссылка на данные ДРУГОЙ базы ?

Если у тебя данные из трех баз слиты в одну то конечно вопросов нет.
   ЧессМастер
 
93 - 17.07.20 - 17:10
(88) Подскажи а как можно реализовать обмен между двумя базами но не через выгрузку - загрузку в файл а через подключение к базе ?

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

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

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

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

Там же если рассмотреть, что это Универсальная загрузка делает с использованием обработки и через файл,
то она все равно пользуется своим планом обмена в конфигурации, который для этих универсальных предусмотрен.
Но правила там берутся своим способом, не так как в других планах и все.
   ЧессМастер
 
95 - 20.07.20 - 10:41
(94) "Когда данных много, то обработка порциями -- источник пометил, выгрузил, Приемник получил и дальше погнал."

Это понятно.

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

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

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

У меня между базами уже поднят другой план обмена где настроен обмен через файл. С периодичностью раз в 2 минуты. Но там мало данных передается.
   Фрэнки
 
96 - 20.07.20 - 10:45
(95) Но прямое подключение, насколько я сам себе смог заметить, оно работает через временный файл. Т.е. создает передаваемый пакет для порции данных из помеченных на передачу в узел.
И пхает этот в приемник. Но порция передаваемых данных ограничена пакетом.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.