Коллеги, всем привет! У меня как всегда пятничная тема и нужен совет.
Есть головная организация в центральном регионе, которая юзает УПП. Есть  филиал в Екатеринбурге и Владивостоке, но проблема в том, что ночью (по МСК) основная база проходит регламентное обслуживание (ТИИ, обновление, перепроведение по партиям) и работать в ней невозможно. Поэтому сейчас перед ночными процедурами для работы региональных филиалов делаем бэкап-рестор, в 10 часов по Москве самодельной обработкой грузим "набитые" данные и отрубаем ее, юзеры продолжают работать. Нюанс в том, что нумерация в пределах организации должна следовать по порядку. В начале рабочего дня на несколько дней вперед обработкой "набиваются" пустые болванки документов, которые резервируются за филиалом, но это костыль. Вопрос: как можно организовать работу филиалов при недоступности основной базы с минимальными коллизиями? Подскажите насчет репликации SQL-ной, на ней бы взлетело? Правда, пока вскрылся один очевидный нюанс - нельзя переносить таблицы итогов и их придется пересчитывать с определенной периодичностью в обоих базах...

Я понимаю, что мой вопрос не совсем по теме и вполне пойму, если у вас появится желание сказать: "ну опять эти умники не по делу лезут, лучше бы советом помогли", но все же, что мешает использовать РИБ?

(1) После перепроведения прикинь какой обмен будет?

(1) Приблизительно 4000 документов. Каждый день. Когда он будет делаться? И опять-таки - как быть с нумерацией?

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

Ну как-то же вы импортируете эти 4000 документов сейчас.

(3) угу, уже тоже про это подумал. А с какой целью вам нужна сквозная нумерация между филиалами? Может от неё возможно отказаться?

4к документов это немного, у нас по 400-500 тысяч записей РС грузится, не наборами, а каждая запись отдельно, жить можно

по нумерации - префиксы ИБ не катят?

(5) Только 50 максимум документов выгружаем из копии и все.
(6) Попробую продвинуть эту тему, но, однозначно, не ранее следующего года... Хотя, у нас все в России можно делать задним числом.

(8) Какая разница - нужна сквозная же нумерация. А в типовой при установке префикса отсчет пойдет с 1.

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

(9) Я правильно понял? Филиалы с базой №2 работаю только ночют по Москве?

с нумерацией при РИБ будет засада конечно, если без префиксов

репликацию не предлагать?

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

(14) Я в теме написал >>  Подскажите насчет репликации SQL-ной, на ней бы взлетело? Правда, пока вскрылся один очевидный нюанс - нельзя переносить таблицы итогов и их придется пересчитывать с определенной периодичностью в обоих базах...

Либо префикс, либо номерами рулит какой-нибудь общий web-сервис.

(0) как вариант извращения могу предложить методику: в час X ставится дата запрета редактирования (для всех, полные права включительно, исключений нет вообще). Снимается копия, делается восстановление по партиям и другие сервисные фишки на копии, регистрируются на узле все изменения (естественно его предварительно надо очистить), тащатся в рабочую базу через любой удобный обмен. А сервисное обслуживание SQL (реиндексация и прочее) вроде не должно столь дико вешать систему. По репликации, увы, не могу ничего сказать ибо не пользовался :( Почитал, вроде бы вкусно.

(15) Как вариант из отрестореной базы сделать периферийный узел.
И делать обмен в одну строну.

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

(18) Можно использовать только репликацию слиянием, но там если будут коллизии, запаришься разгребать. Если на стороне приложения 1С еще можно коллизии решить, то если будет в SQL - тут придется очень сильно попотеть:3

(18) >> как вариант извращения могу предложить методику: в час X ставится дата запрета редактирования (для всех, полные права включительно, исключений нет вообще)

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

(16) вариант типа как в (19), проще... И если делать только ради 40 документов, то возможно лучше его. Репликацию поднять довольно сложно, хотя, если базы будут абсолютно идентичны, то проблем явно меньше чем обычно будет. Зато плюсы очевидны(+ при возможном крахе боевого сервера перевод всех пользователей в реплику займет минут 10)

(19) Так изначально и было, но при получении номеров по КОМ они постоянно дублирвоались...

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

(23) При репликации придется при любой реструктуризации править правила репликации и она возможно только слиянием, то есть, проводится через промежуток времени и есть вероятность, что "слетит" нумерация (основная база не знает про нумерацию первой).

(25) + но судя по всему это потребует дописывать механизм запрета редактирования. Ибо там с точностью до дня, а нам бы до секунды надо. Так что тоже так себе план :(

(25) А, все правильно, что-то сразу не догнал. Но они свои документы иногда правят задним числом. Может быть, каким-то образом отдельно такие правки регистрировать, а потом "накатывать" после обмена их?

(20) Спасибо за идею Ymryn, попробую ее проработать. Ну и с репликацией поиграюсь:3

(28) а у тебя уже последовательность восстановлена при других данных. Если ты их накатишь, тебе надо всю последовательность вновь с этого момента гнать, если все правильно делать. Т.е мы можем придти к ситуации, что все что сделалось на копии все в пустую было.

(30) Это будет маленькая издержка такого обмена (наверное).

(31) а я все таки за репликацию... можно даже делать РИБ таким макаром... http://www.softpoint.ru/products_id28.htm

вот мы по образу и подобию делали