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

И тишинаа.

А зачем РИБ если 8.3 поддерживает тонкий / веб клиент?

В РС, РН однозначно разделитель "Проект" и дописывать проведение доков и доработать отчеты.

(2) Для некоторых подсистем Работа почти круглосуточная.
Стабильный интернет не всегда гарантирована на 100%

(4) купи свисток как резервный
а при самописном РИБ геморой 100% не гарантирован?

(5) Объекты у меня в основном вахтовые городки.
Инет если отрубается то отрубается по причине отключение электричества в соседнем селе. Для таких случаев у нас есть свои генераторы. Да и резервные альтернативные каналы в таком случае только спутниковые каналы. А они очень дороги.
Новы объект пока не подключили к сети электросетей. Пока работаем на генераторе.

сколько узлов будет?

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

(7)Пока 2 ПБ, будет еще как минимум 2.

нужен не общий реквизит, а немигрирующая константа или мигрирующий справочник со структурой РИБ со значением префикса и подписка "ПриУстановкеНовогоНомера" на всё, что мигрирует, даже если "всё всем".

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

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

(11 Если уж сказал что 2 ПБ значит ЦБ есть.

(12) Идея хорошая именно для тех объектов которые пришли с другой базы.

(10) подписка "ПриУстановкеНовогоНомера" -  уже реализвано.

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

(16) В типовых все реализвано относительно ораганизаций или структурных подразделений.

А приныцпе особых сложностей нет. Хотел просто услышать некие премудрости может есть кто через это проходил. Тем более в самописке.

(6) спутник давно уже реальность, но правда не для всех регионов.
Покрытие: http://kitenet.ru/coverage/
Цены: http://kitenet.ru/rates/

(17) добавь ведение списка объектов, которые могут меняться только в ЦБ. Это тебе сильно облегчит жизнь в последствии, когда можно добавить только строчку с типом нужного МД для запрета их редактирования в узлах и не переписывать половину конфы

"Все справочники мигрируют везде. А вот  документы только по кадрам и перемещения." - это ключевая фраза во всей постановке задач.

Рисуешь свой собственный план обмена по образцу полного и авторегистрацию объектов ставишь в соответствии с этой фразой.

Либо, если нельзя менять конфигурацию - используешь полный план, но тогда нужно сделать регламентное задание, которое будет непосредственно перед обменом регистрацию объектов перезаполнять (очищать по тем объектам, которые выгружать не надо).

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

(18) спутник для работы RDP и тонкого - очень печален.

(20) - это касается ПБ. Для ЦБ в плане нужно еще дорисовать отбор по организации или проекту (или еще что там у тебя в качестве разделителя по филиалам)

Можно все эти отборы реализовать и в самих правилах обмена... Короче вариантов масса - выбирай приемлемый для себя

Книжка есть по планам обмена из серии проф. разработка.
Пригодится для идей.

(23) тупиковый путь. правила обмена - это как раз фильтр, накладываемый на зарегистрированные изменения.
один раз он слетит - создадут новую настройку обмена, или удалят правила - и в ЦБ полетят 100500 документов, которых там не должон быть.

управлять нужно именно регистрацией изменений.

(25) это да, безусловно. Ну просто, как вариант, если изменений конфы не планируется, то можно один раз настроить правила выгрузки данных в самих правилах обмена. Регистрация увеличивает размер самой базы, так как для каждого объекта помимо самой таблицы БД создается еще таблица регистрации...

+ еще можно не париться и выгружать/загружать все через обработку универ обмена xml с заранее написаными правилами.
конфу загрузить через поставку, чтобы не меняли.

это будет самым простым вариантом, для случаев, когда конфа редко
меняется

(27) я именно об этом)))

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