У всех баз конфигурации идентичны (БП 2.0 + "дописки"). Все базы друг от друга удалены. Локальная сеть через хамачи настроена.
Схема обмена: http://s2.ipicture.ru/uploads/20120708/4mzbwbf3.png
Мысли вслух:
1. Думаю, предпочтительнее. Создать план обмена по филиалам (подразделениям). Настроить РИБ. Файл обмена будет выгружаться по электронной почте (сеть не очень стабильная, интернет не везде хороший)
2. Универсальный обмен ХМЛ через правила. Думаю, будет глючить. Тоже все через e-mail.

*По выгрузке на e-mail из БП 2.0... думаю посмотреть реализацию в ЗУП и УТ, переделать/передрать.

Ну во первых, нафейхоа столько баз? этому есть какое-либо обоснование? Если да, интересно было бы услышать.

Планы обмена, но не через почту, а например через dropbox :) или через веб-сервисы

(1) Много начальников, "ревизоров")

(2) Каждый на своем ноуте хочет находиться где угодно и видеть данные в реальном времени) В идеале.

(3) Может, им лучше доступ по RDP дать тогда. И отчетность специально для них допилить?

(0) планы обмена, xml ,веб-сервис

перевести всех на фреш. Правда дописки придется похерить

А по сабжу. Я пробовал, е взлетит, из-за кривой реализации регистрации изменений.

* не взлетит

(7) Аргументы?

2(9) аргументы у 1Сников обычные - "у меня, гения, не вышло, как может выйти у вас, двуутробки?"

(7) Я уже настроил РБД по Полному плану обмена. Это все уже в реальной работе. Хочу "просто" допилить обмен по филиалу и сделать отправку по e-mail. И правила тоже писал, рабочие, но планы обмена надежней.

(11) С учетом всех дописок.

(9) Опыт, сын ошибок трудный

Дано. Около 50 организаций. 5 удаленных филиалов. 25 пользователей всего

Задача. Общая бухгалтерская база.

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

И поимел при интенсивной работе и блокировки и тормоза. А всё из-за кривой реализации таблицы изменений. Т.е. при активной работе (особенно в конце периода когда перепроводятся данные за 3 месяца) быстро накапливаются изменения и появляются блокировки таблицы изменения. (пользователь проводит документ - а ему ошибка блокировки данных). Плюс на таблицу изменений нельзя наложить управляемую блокировку, а значит при загрузки данных по организации А блокируется работа ВСЕХ организаций в базе. Плюс дурацкая реализация регистрации в БП, когда на один проведенный документ по организации генерируют изменения в 20 различных регистрах. Причем в основном это регистры по ИП и отключить без вмешательства это нельзя. Ну и по мелочи в виде идиотской привязки подразделений к складакм (актуально для КОРП), или по моему мнению методологический косяк с справочником РБП

Есть еще косяк с учетом по ИП при УРИБ. К примеру есть документ корректировка книги дохода и расхода. В коде есть проверка на этот документ, причем не через запрос, а тупо перебором через выбрать. А значит если у пользователя стоит ограничения по организациям то постоянно будет ошибка доступа к данным. Плюс если ООО могут параллельно работать, то у ИП есть косяки с управляемыми блокировками по регистрам. Т.е. я запускал параллельно на перепроведения 6 различных организациях, и они нормально работали (база перепроводилась). При этом по ИП я не могу провести документ, потому что выскакивала ошибка блокировки данных. Т.е. в боевом режиме когда в конце месяца ООО будут активно препроводить свои данные все ИП будут курить в сторонке


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

P.S. Всё это актуально для БП 2.0. Как в 3.0 это будет реализовано - неизвестно

(9) ГБ что то наменял в своей базе, ген дир, что то у себя, бух в центральной перепровела все доки за месяц. Каков будет результат при ближайшем обмене?

(14) Исходя из своего опыта могу сказать. Будет попа

Собственно изначально у меня была у каждой организации своя база (почка). Далее типовой УРИБ по организации стекают в одну общую базу. Обратно из общей справочники и конфига

Но в результате интенсивной работы в конце месяца объемы были очень большие. Иной раз часов 20 нужно было для загрузки, и не всегда они удачно загружались. (v8: Заблокировать типовую базу для обменов. А если в это время срочно нужно загрузить обновление?
Поэтому перевел сначала ИП в общую базу, но тут вылез косяк v8: Прикольный косяк в типовой с RLS. А когда уже и основные силы в виде ООО подтянулись в эту единную базу и появилась другая проблема v8: Управляемые Блокировки можно ли повесить на независимый регстр сведения?

Ну и тема на мисте по поводу этого решения v8: Паралельная работа в одной базе БП нескольких организаций

(13), (15) а разве есть альтернатива?

(16) Альтернативы есть всегда.

(0) Твою ж дивизию.... "База гл.буха", "База руководителя".
Плодить сущности в самом начале - не есть хорошо... Повышается энтропия, понижается эффективность...

+18 С энтропией ней нужно бороться! :)

ну и совет на будущее: оптимизация ПО начинается с оптимизации бизнес-процессов. А ты "в самом начале пути" такую мину подкладываешь... Нехорошо!

(0)если есть инет можно ESB шину поднять и использовать асинхронный обмен

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

(13) Спасибо, хотел услышать именно аргументы.