1с бухгалтерия риб. Распределенная информационная база. Пошаговая инструкция и подводные камни. Настройка синхронизации в периферийной базе данных

В данной статье речь пойдет о настройке распределенной базы данных 1С предприятие 7.7, в качестве примера будет использована конфигурация Управление Торговлей 9.2.

Что бы настроить РИБ в 1С 7.7 нужно зайти в конфигуратор и перейти в Администрирование-Распределенная ИБ-Управление.

Затем необходимо конвертировать вашу базу в РИБ, если она ещё не конвертирована в РИБ, для этого нужно нажать кнопку "Центральная ИБ".

Установите Код и Описание как на скриншоте сверху и нажмите "OK". Должно появиться предупреждение как на скриншоте снизу, не обращайте на него внимания и нажмите "Да".
После этого ваша база будет готова для создания периферийных узлов.

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

Нажимаем OK и переходим к следующему шагу - настройке автообмена.

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

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

Теперь выгружаем начальный образ периферийной базы на диск, для этого нажимаем кнопку "Выгрузить данные". После выгрузки начального образа окно управления РИБ будет выглядеть следующим образом:

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

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

Нажимаем кнопку "Добавить" и указываем пусть к пустой папке и нажимаем OK.

Выбираем новую ИБ и переходим в режим конфигуратора.

В пустой папке мы создаем пустую ИБ, поэтому 1С просит указать нас в каком формате будет наша база, выбираем *.dbf. Нажимаем OK.

Теперь загрузим выгруженный на прошлых шагах zip-файл в нашу базу, для этого перейдем в администрирование-загрузить данные.

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

На данном шаге необходимо учитывать правило: Директория выгрузки ЦБ = Директории загрузки ПБ и наоборот, т.е. если в центральной базе мы выгружали в папку out а загружали из папки in, то в периферийной базе мы будем загружать из папки out, а выгружать в папку in. Нажимаем OK и переходим к следующему шагу. Выполняем автообмен. Для этого в центральной базе зайдите в администрирование-распределенная иб-автообмен.

Нажмите кнопку "Выполнить", после чего проделайте то же самое на базе-клиенте. Проделайте операцию автообмена поочередно на каждом из компьютеров несколько раз.

Теперь автоматизируем процесс. Для этого необходимо создать по 4 файла на каждом компьютере. По 2 *.prm файла и по 2 *.bat файла на каждую из операций загрузки-выгрузки.

*.bat файл должен содержать в себе следующую строку:

"<путь к файлу 1cv77.exe>" config /D"<путь к информационной базе>" /N<логин> /P<пароль>/@"<путь к prm-файлу>"

У меня файлы загрузки и выгрузки выглядит так:

"C:\Program Files\1Cv77\BIN\1cv7s.exe" config /D"C:\base\rib\" /Nadmin /P1 /@"c:\download.prm"

"C:\Program Files\1Cv77\BIN\1cv7s.exe" config /D"C:\base\rib\" /Nadmin /P1 /@"c:\upload.prm"

Вы прописываете свои значения. Теперь разберемся с prm-файлами!

Структура файла.prm:

Секция “General” – предназначена для описания основных параметров работы пакетного режима. Возможные параметры:

Output – путь к лог-файлу;
- Quit – нужно ли завершить работу конфигуратора после выполнения всех заданий;
- AutoExchange – нужно ли выполнять автообмен;
- SaveData – нужно ли выполнять сохранение базы;
- UnloadData – нужно ли выполнять выгрузку;
- CheckAndRepair – нужно ли выполнить тестирование и исправление базы.

Возможными значениями данных параметров могут быть 1(Y) или 0(N).

Секция “AutoExchange” – предназначена для определения параметров автообмена. Параметры:

SharedMode – указывает режим работы с базы данных. Если параметр не задан, то будет использоваться монопольный режим;
- ReadFrom - указывает от каких баз следует получать данные. Идентификаторы баз необходимо указывать через запятую. Если же необходимы все, то ставится * ;
- WriteTo - указывает для каких баз следует выгружать данные. Если же необходимо для всех, то ставится * .

Секция “SaveData” – предназначена для определения параметров сохранения базы. Возможные параметры:

SaveToFile – указывает путь, куда будет производиться сохранение;
- FileList – указывает список сохраняемых файлов. Перечисляются имена файлов через пробел или запятую;

Секция “ UnloadData” – предназначена для определения параметров выгрузки данных. Параметры:

UnloadToFile – указывает путь сохранения, включая имя файла;
- IncludeUserDef – указывает нужно ли в файл переноса включать список пользователей;
- Password – указывает пароль,который будет установлен на файл переноса.

Секция “ CheckAndRepair” – предназначена для определения параметров восстановления базы данных. Возможные параметры:

Repair – указывает, необходимо ли проводить восстановление базы данных;
- PhysicalIntegrity – указывает, нужно ли проводить проверку физической целостности таблиц информационной базы;
- Reindex – указывает необходимость проведения реиндексации базы;
- LogicalIntegrity – указывает, необходимо ли проводить проверку логической целостности таблиц;
- RecalcTotals – указывает, необходимо ли производить пересчет итогов бухгалтерского и оперативного учета;
- Pack – указывает, необходимо ли освобождать место, занятое удаленными записями;
- SkipUnresolved – указывает, пропускать неразрешенные ссылки или их исправлять;
- CreateForUnresolved – указывает, способ разрешения неразрешенных ссылок. Если 1, то для неразрешенной ссылки будет создан объект соответствующего типа. Если же 0, то ссылка будет очищена.

Исходя из этого мои файлы будут содержать следующее:

для загрузки из ЦБ в периферийную:

Output = log.txt
Output = 1

ReadFrom = ЦБ

для выгрузки из ЦБ в периферийную:

Output = log.txt
Output = 1

WriteTo = ЦБ

для загрузки из периферийной в ЦБ:

Output = log.txt
Output = 1

ReadFrom = ПБ1

для выгрузки из периферийной в ЦБ:

Output = log.txt
Output = 1

WriteTo = ПБ1

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

Если остались вопросы - wellcome в комментарии!

Часто возникает ситуация, когда организация имеет несколько филиалов или торговых точек, территориально удаленных друг от друга. Тем не менее остается необходимость вести единый учет по всей организации. Одним из вариантов решения этой задачи является создание единой сети, в которую будут включены автоматизированные рабочие места всех филиалов, и размещение информационной базы 1С на общедоступном сервере. Этот способ может быть технически сложен и затратен. Кроме того, возникает ряд вопросов, связанных с информационной безопасностью.

Второй вариант — создание распределенной информационной базы (РИБ). Распределенная информационная база представляет собой иерархическую структуру, состоящих из отдельных информационных баз на платформе 1С:Предприятие, между которыми организован обмен данными с целью синхронизации конфигурации и данных. Эти отдельные информационные базы называются узлами РИБ.

Распределенная информационная база может быть создана на основе различных конфигураций системы 1С:Предприятие. Рассмотрим ее создание на примере 1С:Управление торговлей 10.3.

Допустим, в торговой организации открывается дополнительная торговая точка, в которой необходимо иметь доступ к общей торговой системе организации. Для создания РИБ необходимо выполнить следующие шаги:

На этом создание распределенной информационной базы завершено. Для обмена информацией необходимо запустить обмен данных в Центральной базе (выгрузятся изменения, которые произошли в ней), затем — в магазине (загрузятся изменения из центральной базы и выгрузятся изменения, произошедшие в магазине), и снова — в центральной базе (в нее загрузятся изменения, произошедшие в магазине).

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

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

Если у вас возникли проблемы с настройкой распределенной информационной базы, наши специалисты помогут вам настроить обмен данными и подробно объяснят, как его использовать.

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

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

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

В этой инструкции мы на примере создадим центральную и периферийную базы данных, проверим обмен между ними. Это пособие подойдет как для 1С 8.3 Бухгалтерия, так и для 1С Управление торговлей (УТ) и других конфигураций.

Настройка главной (центральной) распределенной базы РИБ

Зайдем в меню 1С «Администрирование», далее по ссылке «Настройки синхронизации данных». В открывшемся окне нужно установить флажок «Синхронизация данных». Станет активной ссылка «Синхронизация данных». Сразу здесь же установим префикс для главной информационной базы – например, «ЦБ»:

Заходим по ссылке «Синхронизация данных», откроется окно с кнопкой «Настроить синхронизацию данных». При нажатии на эту кнопку откроется выпадающий список, где нужно выбрать режим «Полный». Если требуется синхронизация только по одной организации, нужно выбрать «По организации…».

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

После создания резервной копии нажимаем кнопку «Далее». На следующем шаге нам следует определиться, как будет происходить синхронизация:

• через локальный каталог или каталог в локальной сети;
• по интернету посредством FTP.

Для простоты и наглядности примера выберем локальный каталог. Я указал следующий путь: «D:\Базы 1С\Синхронизация». Не лишней будет проверка записи в данный каталог, для этого есть специальная кнопка:

Получите 267 видеоуроков по 1С бесплатно:

Следующие шаги с настройкой синхронизации по FTP и электронной почте пропускаем. Останавливаемся на настройках названий главной и периферийной баз данных. Здесь же зададим префикс для периферийной базы:

Не забывайте, что префиксы каждой базы должны быть уникальны. В противном случае Вы получите ошибку «Значение префикса первой информационной базы не уникально».

Жмем «Далее», проверяем введенную информацию и опять нажимаем «Далее», затем — «Готово». В поле «Полное имя файловой базы» указываем файл 1Cv8.1CD в каталоге, который создали для синхронизации. Создаем начальный образ распределенной базы 1С:

После создания начального образа РИБ в 1С можно задать расписание синхронизации или синхронизировать вручную:

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

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

Настройка синхронизации в периферийной базе данных

В периферийной базе 1С настройка намного проще. Достаточно установить флажок «Синхронизация данных» и перейти по одноименной ссылке. И мы почти сразу попадаем в окно с кнопкой «Синхронизировать». Попробуем создать тестовую номенклатуру в периферийной базе и выгрузить ее в основную с помощью РИБ:

October 25th, 2016

Между настройкой и поддержкой РИБ на 2 узла и на 10 большой разницы нет, а вот когда число удаленных точек переваливает за сотню, приходится решать уже совсем другие вопросы

Исходные данные:

Конфигурация: Розница 2.2
Платформа 1С: 8.3.7.1970



Срок проекта: год.



Архитектура:

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





Ограничния:
- 2 ГБ ОЗУ
- 1 физический процессор


Из всего вышеперечисленного напрягает в осном ограничение на максимальный объём БД.

Но это всего лишь означает что нужно гработно организовать процедуру её очистки от устаревших данных на местах.

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


Основные настройки

Со времен УТ 10.3, на которой у меня состоялся первый проект внедрения РИБ на 60 узлов, конечно "утекло много воды".

1С не стояли на месте. Розница 2.2 теперь учитывает необходимость выборочной выгрузки данных.
В базу магазина будет выгружаться только та информация которая имеет к нему отношение:
- Все справочники (кроме специализированных)
- Документы по данному магазину

Другой вопрос что так или иначе добавление узла в базу означает добавление ещё одной записи в таблицу регистрации на каждый общий элемент при его записи.





1) Нужно разделить на отдельные сценарии синхронизации на выгрузку и загрузку
Смысл в том, что выгрузка проходит долго и с блокировками, а загрузка достаточно беспроблемно. При этом часто бывает что данные нам нужно оперативно получать из розничных точек, отдавая при этом только несколько раз в день.

2) Выделить проблемные магазины и убрать их из общего сценария синхронизации. На них могут быть большие выгрузки - тормозиться при этом будет весь обмен, включая другие узлы. После решения проблем они доабвляются обратно

3) Создать несколько сценариев отправки и получения данных. Но тут главное поймать правильный баланс их количества.
(ещё с версии 8.1).
Следовательно параллельность в выгрузке РИБ ограничена. На практике получается запускать параллельно 2-3 сценария.


Что пришлось доработать

Самый главный косяк в штатной логике 1С РИБ - это обновления

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

Ещё одна важная деталь - Зачем? Дисконтных карт скопилось уже близко к 3 млн. Для работы с ними используется внешняя online система. Если продолжать передавать дисконтные карты на все магазины - это в разы увеличит обмены, кроме того может привести к превышению базой объёма в 10 ГБ.

Часть механизмов реализована online обращением в центральную базу: остатки в других магазинах, возврат по чеку из другого магазина, проверка валидности подарочного сертификата.


Тиражирование


Создание начального узла РИБ штатным образом сделало бы невозможным тиражирование в принципе.
Поэтому новый узел создаётся следующим образом :


2) Эта база обменивается в РИБ всеми общими данными но не получает специализированных (документов)


5) База для магазина готова.

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


Преимущества тонкого клиента

Два существенных преимущества Розницы 2.2 (Тонкого клиента) которые "согрели душу":








Поддержка и обновления




1) Обновлять руками магазинов (не очень правильно, могут не получить изменения, будут звонки и проблемы) -так было ранее

3) Написать *.cmd или 1С скрипт для обновления или взять готовый. Как показывает практика такое решение всегда половинчатое (нестабильное), а функциональности в нём получится заложить немного.

Какие у нас были задачи:


2) При обновлении возможно интерактивное взаимодействие с пользователем (сообщения, подтверждение, прогресс бар).








Основные функции:




4) Проверка состояния агентов
5) Отчеты об обновлениях
6) резервное копирование

















Вот так, к примеру, выглядит сообщение об ошибке после обновления:

Таким образом у проекта появились неплохие шансы быть завершенным успешно. По крайней мере на середине пути "полёт нормальный".

Если придём ещё к каким-либо решениям которые могут показаться интересными напишу отдельно

P.S. и самое главное: Правльное планирование дальнейшей поддержки - один из ключевых факторов дальнейшего успеха подобных проектов. :)

October 25th, 2016

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

Итак, исходные данные:

Конфигурация: Розница 2.2
Платформа 1С: 8.3.7.1970
Ориентировочное число узлов в конце проекта: 200
Ресурсы оборудования в центре: без существенных ограничений
Оборудование на точке: обсуждаемый вопрос.
Срок проекта: год.

Архитектура:

Сперва определились со схемой РИБ. Было принято решение ориентироваться на схему "звезда", до той
В торговых точках используется клиент-серверный вариант работы, с выделенным сервером, под управлением ОС Windows.
Сервер 1С будет использован в варианте "Сервер 1С МИНИ" https://1c.ru/news/info.jsp?id=17577
Сервер СУБД - MS SQL Express 2008 R2.

SQL Express 2008 R2 - последняя на текущий момент времени версия данной линейки SQL Server.
Ограничния:

2 ГБ ОЗУ
- 1 физический процессор
- 10 ГБ максимальный объём базы

Из всего вышеперечисленного напрягает конечно в осном ограничение на максимальный объём БД. Но собственно это всего лишь означает что нужно будет гработно организовать процедуру её очистки от устаревших данных на местах.

Под сервер 1С и MS SQL выделяется отдельный сервер. На него будет ложиться основная нагрузка по обменам и проведению операций.
Конечные клиентские компьютеры не заменяются, потому как будут работать с тонким клиентом и нагрузка на низ будет минимальной.
Сервер в магазине - просто мощьный ПК. Но обязательным условием является наличие диска SSD - на котором расположены базы MS SQL .
Также сервер будет обсепечивать возможность проведения регламентных операций в ночное время и доступ к базе магазина без отрыва от работы.

Основные настройки

Со времен УТ 10.3 на которой у меня состоялся первый проект внедрения РИБ на 60 узлов конечно "утекло много воды". 1С не стояли на месте. Розница 2.2 теперь учитывает необходимость выборочной выгрузки данных.
В базу магазина будет выгружаться только та информация которая к немиу имеет отношение:
- Все справочники (кроме отдельных)
- Документы по данному магназину
Регистрация данных происходит по правилам регистрации, всё что можно кэшируется. Существенных замедлений именно на регистрации не наблюдается.
Другой вопрос что так или иначе добавление узла в базу означает добавление ещё одной записи на каждый общий элемент для всех баз.

В настройке самой выгрузки ничего специфичного нет. Есть некоторые нюансы принастройке сценариев синхронизации:

1) Нужно разделить на отдельные сценарии синхронизации выгрузку и загрузку
Смысл в том, что выгрузка проходит долго и с блокировками, а загрузка достаточно безпроблемно. При этом часто бывает что данные нам нужно оперативно получать из розничных точек, отдавая при этом только несколько раз в день.

2) Выделить проблемные магазины и убрать их из общего сценария синхронизации. На них могут быть большие выгрузки - тормозиться при этом будет весь обмен, включая другие узлы

3) Создать несколько сценариев отправки и получения для отправки и получения данных. Но тут главное баланс.
Некоторые вещи в 1С не меняются. Тот самый метод "ВыбратьИзменения" может выполняться только последовательно (ещё с версии 8.1).
Следовательно параллельность в выгрузке РИБ ограничена. На практике получаетсы выгружать единовременно 2-3 сценария.
Что касается сценариве получения - тут возможна куда большая параллельность, если нужна конечно.

Что пришлось доработать

Конечно грустно и печально, но пришлось основательно влазить в БСП. Самый главный косяк в штатной логике 1С - это обновления . После обновления появляется примерно такое окошко:

Это всё происходит в монопольном режиме. Кроме всего прочего, система ещё будет пытаться сделать обмен после обновления в монопольном режиме. К чему это все приводит - не трудно догадаться.
Весь этот период времени магазин не может работать, на кассе стоят покупатели, компания теряет деньги.

Ещё одной проблемой обмена становятся регистры сведений. Выгрузка в XML каждой записи регистра сведений создаёт отдельный узел XML со служебными элементами и всем отсюда вытекущим. Кроме того, функция "выбрать изменения" для регистра сведений в котором 100 записей результирующая таблица будет содержать 100 строк, в то же время, есдли это справочник у которого 100 строк в табличной части выберется только одна запись. Так что если в РС много записей, которые регулярно регистрируются к обмену в другие магазины то это конечно правильне представить в виде справочника с табличной частью, который в крайнем случае при записи может формировать записи этого же регистра. В любом случае, регистры сведений в обменах - это зло .

Ещё одна важная деталь - из обмена польностью исключены дисконтные карты, а физлица - только сотрудники конкретного магазина. Зачем? Дисконтных карт скопилось уже близко к 3 млн. Для работы с ними используется внешняя online система. Если продолжать передавать дисконтные карты на все магазины - это в разы увеличит обмены, кроме того может привести к превышению базой объёма в 3ГБ.

Часть механизмов реализована online обращением в центральную базу: остатки в других магазинах, возврат по чеку из другого магазина, проверка валидности подарочного сертификата.

Тиражирование

Конечно тиражирование ведётся ускоренными темпами.
Создание начального узла РИБ штатным образом конечно сделало бы невозможным тиражирование.
Поэтому новый узел создаётся следующим образом:

1) Существует отдельная база с фейковым магазином
2) Эта база обменивается в РИБ всеми общими данными но не получает специализированных
3) Когда хотим создать новую базу - просто копируем эту
4) Потом устанавливаем настройки - магазин, префикс и т.п.
5) База для магазина готова.

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

Преимущества тонкого клиента

два существенных преимущества которые "согрели душу".

1) Нет необходимости менять весь компьютерный парк в торговых точках. 90% операций выполяется на сервере, а сервер туда привозится "относительно мощный компьютер"

2) Техника имеет свойства отказываться работать, особенно часто это происходит с вновь установленным или уже изношенным оборудованием.
В этом случае действия теперь предельно просты - магазин переключается на работу в центральной базе.
Этот процесс занимает не более 5-10 минут, таким образом торговля не прерывается даже при существенных проблемах с оборудованием.

Поддержка и обновления

Наконец дошли до самого интересного пункта - как же всё это поддерживать и обновлять?
Для нас обновления тоже долгое время были делеммой:

1) Обновлять руками магазинов (не очень правильно, могут не получить изменения, будут звонки и проблемы)
2) Обновлять силами технической поддержки (нет столько ресурсов)
3) Написать *.cmd для обновления или взять готовый. Как показывает практика такое решение всегда половинчатое (нестабильное), а функциональности в нём немного.

Какие у нас были задачи:

1) Обновление должно проходить в нескольких режимах и урпавляться централизованно
2) При обновлении возможно интерактивное взаимодействие с пользователем.
3) Обязательно должны приходить отчеты о состоянии и ошибках обновления
4) Должно быть резервное копирование
5) Система обновления должна уметь без проблем обновлять саму себя.
6) Система должна быть расширяема без особых проблем.

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

Основные функции:

1) Динамическое обновление базы (команда или по расписанию)
2) Статическое обнволение базы (команда или по расписанию)
3) автоматическое агентов на конечных компьютерах при их модификации
4) Проверка состояния агентов
5) Отчеты об обновлениях
6) резервное копирование
7) Административные действия с сервером 1C и MS SQL
8) Закрытие всех клиентских приложений 1С на компьютерах сети
9) Статическое обновление с акцептом на главной кассе
10) Отображение описания модификаций после обновления
11) Настройка порядка действий
12) Выполнение всех этих действий по расписанию

Примерная схем взаимодейтсвия:

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

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

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

Приложения конечно не 1С-ные, но с достаточно приличным набором интерфейсных возможностей. Вот так, к примеру, выглядит отбор по дате:

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

краткая характеристика
Количество установок	не ограничено	Использование с компонентой Бухгалтерский учет 7.7	да
Количество периферийных баз данных	не ограничено	Использование с компонентой Оперативный учет 7.7	да
Самостоятельная программа	нет	Использование с компонентой Расчет 7.7	да
Тип ключа защиты	USB	Доставка по России включена в стоимость	да
Дистрибутив в комплекте	да	Особенности покупки	по заявлению
Руководство по установке в комплекте	да

Для чего нужно 1C:Предприятие 7.7. Управление распределенными информационными базами (1С УРБД, 1С УРИБ)

Сокращения и аббревиатуры: 1С УРБД - Управление распределенными базами данных; 1С УРИБ - Управление распределенными информационными базами.

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

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

Компонента 1С УРБД может использоваться только с профессиональными версиями программ системы "1С:Предприятие 7.7".

Сколько штук "1C:Предприятие 7.7. Управление распределенными информационными базами" нужно купить, например, для головного офиса и двух удаленных складов?

Компонента "1C:Предприятие 7.7. Управление распределенными информационными базами" - 1С УРБД - устанавливается для центральной информационной базы. Одна компонента позволяет синхронизировать неограниченное количество периферийных информационных баз. Т.о., например, для синхронизации головного офиса и двух удаленных складов необходим один экземпляр "1C:Предприятие 7.7. Управление распределенными информационными базами".