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

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

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

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

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

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

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

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С-ные, но с достаточно приличным набором интерфейсных возможностей. Вот так, к примеру, выглядит отбор по дате:

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

Для создания распределенной информационной базы необходимо зайти программу в режиме "1С: Предприятие". Для создания узлов распределенной базы в меню выбираем: Операции - Планы обмена. Откроется окно «Выбор объекта: План обмена».

1. Рассмотрим вариант с планом обмена «Полный».

Обмен будет, осуществляться по всем организациям, находящимся в распределенной информационной базе.

Выберем план обмена «Полный». Откроется окно «План обмена полный».

Заполняем две записи:

Первую запись назовем «Главный узел», код укажем «ГУ»,

Вторую запись назовем «Подчиненный узел», код укажем «ПУ».

Как видим из рисунка, у первой записи значок изображен с зеленным кружком, это значок «Главного узла».

Для создания копии информационной базы «Главного узла», кликаем на «Подчиненный узел» и нажимаем на значок «Создать начальный образ». Это будет информационная база «Подчиненного узла».

Откроется окно «Создание начального образа ИБ», выбираем «На данном компьютере или на компьютере в локальной сети», нажимаем «Далее».

В поле «Каталог информационной базы» выбираем местоположение, куда будет установлена копия «Главного узла», нажимаем «Готово».

После создания информационной базы «Подчиненного узла» появится сообщение:

Нажимаем «Ок».

Добавляем информационную базу «Подчиненного узла» в "1С: Предприятие". Заходим в подчиненную базу в режиме "1С: Предприятие". Откроем: Операции - Планы обмена. Откроется окно «Выбор объекта: План обмена». Выберем план обмена «Полный». Откроется окно «План обмена полный». Видим что значок «Главного узла» оранжевый, это значит, что этот узел является главным для той информационной базы, в которой мы находимся.

Следующие настройки делаем и в Главном и в Подчиненном узле:

1. Добавляем префикс для распределенной информационной базы.

Это делается для того чтобы не возникало конфликтов в номерах и кодах документов и справочников, созданных в двух базах, поэтому в каждой базе указываем префикс, который будет добавляться в номера документов и коды справочников. Открываем: Сервис - Настройка программы - закладка «Обмен данными». В поле «Префикс узла для распределенной информационной базы:» в подчиненной базе вводим «ПУ», в главной базе вводим «ГУ».

2. Добавляем настройку обмена данными между узлами:

Открываем: Сервис - Распределенная информационная база (РИБ) - Настроить узлы РИБ. Откроется окно «Настройки обменов данными».

Нажимаем «Добавить», откроется окно «Настройка обмена данными». Вводим «Наименование» вашей настройки.

В поле «Узел» автоматически появится узел, для «Главного узла» будет «Подчиненный узел», для «Подчиненного узла» будет «Главный узел».

В поле «Каталог» выберете папку, в которую будут поступать данные обмена, для главной и подчиненной базы лучше всего указывать один каталог.

В поле «Тип обмена» настраиваем передачу данных между базами: через файловый или фтп-ресурс. Выбирем например «обмен через файловый ресурс».

В остальных полях ничего не меняем.

Нажимаем «Ок». Видим, что появилась настройка.

3. Для обмена данными делаем следующее:

Сначала в базе, в которой были сделаны изменения, нажимаем на значок «Выполнить обмен по текущей настройке», как показано на рисунке.

После выгрузки появится окно результата выгрузки.

Потом в базе, в которую необходимо передать изменения, нажимаем на значок «Выполнить обмен по текущей настройке» и данные попадут в ту базу, в которую вы хотите.

2. Рассмотрим вариант с планом обмена «По организации».

Обмен будет, осуществляется по выбранным организациям, находящимся в распределенной информационной базе.

Для создание узлов распределенной базы в меню выбираем: Операции - Планы обмена. Откроется окно «Выбор объекта: План обмена».

Выберем план обмена «По организации». Откроется окно «План обмена По организации».

Заполняем две записи:

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

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

Во всем остальном настройка идет абсолютно аналогично с «Планом обмена: Полный».

В этом материале подробная инструкция по настройке обмена РИБ для 1С:Предприятие 8 и проблемы, с которыми столкнулся автор.

1. Создание узлов
Создаем новые узлы (главный и подчиненный): в пользовательском режиме "Операции / Планы обмена/Полный"
Выберем план обмена "Полный"
Создаем две записи:
- первую запись назовем "ЦБ" (главный узел), код укажем "ЦБ",
- вторую запись назовем "Подчиненный узел", код укажем "ПУ".
Значек с зеленным кружком - "ЦБ" (главный узел)

Для подчиненного узла нажимаем на иконку "Создать начальный образ". (Потребуется монопольный доступ)
Создать начальный образ
Далее в открывшемся окне заполняем параметры новой базы. По окончании нажимаем кнопку "Готово"
Создание начального образа ИБ
Начнется создание начального образа подчиненного узла распределенной информационной базы, по окончании появится сообщение "Создание начального образа успешно завершено". Жмем кнопку "ОК".
Добавляем базу подчиненного узла в список баз, запускаем ее.
В этой подчиненной базе открываем полный план обмена - значок "ЦБ красный, это значит, что этот узел является главным для информационно базы, в которой мы находимся.

2. Настройка префиксов
Для каждой базы, в настройках параметров учета (в УПП "Сервис / Параметры учета") на закладке "Обмен данными", устанавливаем префиксы. Это делается для того чтобы не возникало конфликтов в номерах и кодах документов и справочников, созданных в двух базах.
Для автообмена, устанавливаем галочку "Использовать механизм автоматического обмена..."
Закладка "Обмен данными"

3. Добавляем настройку обмена данными между узлами
Открываем: "Сервис \Распределенная информационная база (РИБ)\Настроить узлы РИБ"
Нажимаем "Добавить", откроется окно "Настройка обмена данными"
Настройка обмена данными

Нажимаем на значок "Выполнить обмен по текущей настройке"
Выполнить обмен по текущей настройке

Теперь о "подводных камнях"
1. Обмен данными может выполняться в автоматическом режиме и может быть инициализирован в следующих случаях:
* При запуске программы. Обмен будет выполняться при запуске программы,
* При завершении работы с программой. Обмен будет выполняться перед завершением пользователем работы с программой,
* При появлении каталога. Обмен будет выполнен только в том случае, если каталог указанный пользователем был невиден, а в настоящий момент стал виден. Настройка может быть использована для выполнения автоматического обмена при подключении к локальной сети или flash карты. Программа периодически будет проверять видимость указанного в настройках каталога и отмечать его текущее состояние,
* При появлении файла. Рекомендуется использовать данные режим, когда нужно выполнить обмен, если появляется входящий файл обмена данными. В этом случае, достаточно указать полный путь к входящему файлу обмена данными. Программа периодически анализирует наличие файла, и как только он появится, будет выполнен обмен, а после обмена этот файл будет принудительно УДАЛЕН (это делается для того, что бы процедура обмена не выполнялась постоянно),
* Периодический обмен данными. Обмен будет выполняться согласно настройкам периодического обмена данными. Если информационная база работает в файл-серверном режиме, то периодический обмен выполняется только у пользователя, который указан в параметрах учетной политики как "Пользователь для регламентных заданий в файловом режиме". В Клиент-серверном варианте обмен выполняется на сервере 1C:Предприятия.

У меня Клиент-серверный вариант - для работы регламентного автообмена пришлось перегружать сервер

2. Кодировка Windows.
Обмен прерывался ошибкой - так как не происходит сжатие файла. Это из-за ошибки кириллицы в командной строке при сжатии.
Лечится исправлением кодировок в реестре.
Например, для Windows Server 2008 -
Код

REGEDIT4
"1250"="c_1251.nls"
"1251"="c_1251.nls"
"1252"="c_1251.nls"
"1253"="c_1251.nls"
"1254"="c_1251.nls"
"1255"="c_1251.nls"

3. Создавая копию базы (например, для доработки) в клиент-серверном варианте, НЕОБХОДИМО, чтобы РЕГЛАМЕНТНЫЕ ЗАДАНИЯ КОПИИ базы были ВЫКЛЮЧЕНЫ. Блокировка регламентных заданий для копии ВКЛ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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