Быстрое создание риб розница 1с 8.3. Распределенная информационная база: Основы

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

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

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

==== Настройка для главной базы ====

Открыв 1С 8.3 в режиме «Предприятие» перейдем в раздел «Администрирование». В версии 1С 8.2 для начала работы нужно перейти в главном меню «Сервис» — «Распределенная информационная база (РИБ)» — «Настроить узлы РИБ».

Далее будем рассматривать процесс в контексте ИБ версии 8.3. Итак, перейдя в раздел «Администрирование», выберем «Настройка программы». В настройках зайдем в раздел «Синхронизация данных». Здесь ставим галочку «Использовать синхронизацию данных» и указываем префикс базы данных. Укажем «ЦБ», подразумевающий центральную базу.

После этого в правом меню появляется пункт «Синхронизация данных». Выберем его. В открывшемся дочернем окне нажимаем кнопку «Настроить синхронизацию данных». В выпадающем меню можно выбрать варианты настроек под различные случаи использования синхронизации. Мы выбираем «Распределенная информационная база…».

Для общего развития знакомимся содержимым следующего окна и нажимаем «Далее».

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

Следующие два окна предназначены для указания параметров настроек для случаев обмена через сервер FTP и через электронную почту. Как указывалось ранее, мы рассматриваем способ обмена через каталог, поэтому настройки для FTP и email пропускаем.

Следующее окно предназначено для указания параметров обмена в части периферийной базы данных. Укажем ее название и префикс. Далее — кнопка «Далее».

Проверим сформированные нами параметры обмена и подтвердим их правильность традиционной кнопкой «Далее».

Автоматически будет создан необходимый набор настроек для обмена. Это займет некоторое время.

Важно! Создание начального образа для подчиненного узла занимает значительное время. Размер этой значительности зависит от ресурсов компьютера и объемов учета в главной базе данных.

Предположим, что мы решили создать образ. После нажатия на кнопку «Готово» в предыдущем окне, введем настройки для создания образа подчиненной ИБ. Мы рассмотрим простейший случай для локальных операций. Для этого укажем нужные реквизиты в открывшемся окне. Особо обратим внимание на параметр «Полное имя файловой базы». Его необходимо указывать в полном формате UNC, который предполагает формирование и локального пути в «сетевом» формате. Например — «\\Server1C\Databases\RIB». К указанному пути добавим наименование файла БД — 1Cv8.1CD.

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

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

==== Настройка для периферийной базы ====

Для этого ее нужно подключить к 1С. Как это сделать вы найдете в инструкции в нашей статье — После подключения, новую базу нужно запустить в режиме конфигуратора и создать пользователей. Далее ИБ нужно запустить в режиме 1С «Предприятие».

Если, по какой-либо причине, создание пользователей нужно перенести на более позднее время, можно после подключения просто запускать базу в режиме 1С «Предприятие». Будет предложено создание пользователя «Администратор», согласитесь с ним, и будет выполнено начальное заполнение.

Затем нужно продолжить настройку сопряжения с главной базой. Эта настройка подобна рассмотренной выше для главной базы.

Будет создана настройка для связи с главной базой.

============================================

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

Сделаем это в главной базе данных. Периферийная база настраивается аналогично.

Редактирование можно применить к правилам и расписанию синхронизации данных.

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

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

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

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

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

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

Скачать иллюстрированную инструкцию

Распределенная информационная база. Пошаговая инструкция
Распределенная Информационная База (РИБ) 1С:Преприятие
Создание распределенной информационной базы и ее настройка
как настроить риб в 1с 8.2
Как настроить распределенную информационную базу в 1С
Как настроить в 1С
Как настроить в 1С
Настройка распределенной информационной базы (РИБ) в 1С
Пример настройки РИБ для 1С:Бухгалтерии 8
Создание распределенной информационной базы и настройка

Это моя первая в жизни статья, конструктивная критика приветствуется.

Целевая аудитория - те, кто первый раз сталкивается с РБД.

Задачи РБД

Первое с чего необходимо начать - это ответить на вопрос «Зачем нам нужна РБД?». Вариантов ответов много, в частности:

1. У нас есть филиалы, работающие в несвязных БД. Теперь мы хотим, чтобы информация между ними синхронизировалась;
2. У нас есть филиалы, однако нагрузка на базу слишком велика (имеются ввиду блокировкитранзакций, не объем БД) и онлайн актуальность (не путать с актуальностью в несколько минут, онлайн - это когда после выполнения каждой транзакции данные передаются во второй узел) данных для филиалов не требуется;
3. У нас есть филиалы, в которых происходит только ввод данных (например, розничные магазины), поэтому можно существенно снизить нагрузку на центральную БД;
4. Из соображений безопасности мы хотим, чтобы в филиалах даже теоретически(с админ. паролем) не было доступа к важным данным, например балансу предприятия.

В одном случае для меня были актуальны вопросы 2 и 4, в другом 2 и 3. Первый пункт слишком обширный и в рамках тематики данной статьи рассматриваться не будет.

Также лучше сразу рассмотреть проблематику транспорта файлов обмена, потому что в некоторых случаях она может наложить существенные ограничения на реализацию обмена данных. Сначала необходимо определить в каких филиалах точно появятся узлы РБД (обычно это региональные филиалы). Далее рассматриваем, где ещё мы хотим установить узлы РБД, и нужна ли в них онлайн актуальность. Например, для розничных магазинов далеко не всегда есть возможность установки даже модема, а установка беспроводной связи будет слишком дорогая. Здесь необходимо принять решение - возможно, данный магазин может работать в оффлайне и периодически обмениваться с центром (раз в день/раз в неделю) с помощью физического носителя, например флешки.

В некоторых случаях обмен посредствам физического носителя невозможен, например это очень удаленный филиал, где есть существенные проблемы с наладкой высокоскоростной связи. Здесь стоит примерно подсчитать объем информации при обмене. Часто при актуальности раз в час либо несколько раз в день достаточно 32к модема. Однако стоить помнить, что вместе с обновлениями данных придется иногда присылать обновления самой конфигурации или внешних файлов (печатный формы, фотографии товаров), поэтому периодически будет возникать ситуация, когда файл обмена существенно увеличиться из-за таких обновлений.

Топология

Итого мы получили следующие вопросы, на которые необходимо ответить:

1. В каких подразделениях мы гарантированно будем устанавливать узлы РБД и есть ли там возможность установить высокоскоростной канал;
2. В каких подразделениях установка узла РБД не требуется;
3. Какие подразделения могут работать с актуальностью в несколько часов;
4. Какие подразделения могут работать в оффлайн режиме (обмен данными меньше 3-4х раз в день).

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

Рис 1. Типовая схема РБД крупной компании

Если с узлами «Филиал» все относительно ясно - это крупные центры, требующие автоматизации, то под узлами «Магазин» подразумевается узел с серьезной нагрузкой на БД при вводе данных, который для снижения нагрузки следует отделить. Например, магазин с 50-тью кассами и ежедневным товарооборотом больше 10000 единиц.

• Магазины - ввод данных о собственном товарообороте и движении денежных средств. Аналитика поверхностная, только по своему магазину.
• Филиалы - ввод данных неавтоматизированных точек, бухгалтерия, зарплата и кадры, производство и т.п. Аналитика в рамках собственного филиала.
• Центр - ввод данных неавтоматизированных филиалов. Аналитика предприятия в целом.

Важно понимать в каких целях будет использоваться БД в каждом узле. От целей выстраиваются задачи, необходимые к реализации, например:

• Филиалы видят историю взаиморасчетов с контрагентами друг друга;
• Магазины видят остатки товаров во всем (либо части) предприятия;
• Аналитика доходов/расходов, выполнения бюджета и т.п.видны только в рамках иерархии собственного подразделения;
• Бухгалтерия, зарплата и кадры видны только в рамках иерархии собственного подразделения;
• Номенклатура, все её свойства и характеристики видны во всех узлах РБД;
• Относительно иерархии подразделений все данные попадают вверх, но фильтруются вниз;
• В центр попадает абсолютно вся информация о компании.

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

Теперь, в зависимости от потоков информации, перерисуем схему РБД:

Что мы видим на рисунке 2? Согласно иерархии подразделений компании выстроилась топология потока информации между узлами БД. Также добавился узел «Центр 2», почему? При реализации топологии «Звезда» нагрузка на центр всегда выше, чем нагрузка на периферийные узлы, при этом часто нагрузка, генерируемая самим узлом, и так высока. Примеры использования узлов «Центр 1» и «Центр 2»:

1. «Центр 1» служит только для консолидации данных остальных узлов РБД. Доступ к нему имеет только администратор. «Центр 2» служит для работы головного офиса;
2. «Центр 1» служит для работы головного офиса. Однако тяжелые аналитические, тестовые, создающие огромную нагрузку на БД, операции выполняются в узле «Центр 2»; например восстановление последовательности, перепроведение закрытых периодов, формирование сводных отчетов по всему предприятию за длительный промежуток времени, формирование аналитики, приводящей к изменению данных;
3. «Центр 1» служит для работы головного офиса. «Центр 2» является резервным, на случай непредвиденных ситуаций для быстрого восстановления всей РБД.

Реализация обмена

Существуют 2 варианта работы РБД:

1. Автоматический - происходит без участия пользователя. Контроль за внештатными ситуациями,возложен либо на администратора БД, либо на продвинутого пользователя;
2. Ручной - обмен происходит только по желанию пользователя.

По своему опыту приводил все реализации всегда к автоматическому варианту. Если были проблемы с транспортом файлов обмена (наличие сети в узле не постоянно), то максимум, что позволял пользователю - это нажать кнопку «Произвести обмен сейчас». Ситуации, когда помимо обновления данных идет обновление конфигурации желательно приводить тоже к полностью автоматическим (например, используя стороннее ПО).

Формирование пакетов обновлений

Так как есть однозначное решение о том, на какие узлы РБД возложены какие функции, то можно сформировать только тот пакет данных, который нужен этому узлу. С одной стороны, необходимо указать какие типы объектов будут синхронизироваться между узлами. Например, регистры бухгалтерии для узла «Магазин 1» не должны вообще синхронизироваться, т.к. данные вводятся только на уровне узла филиала. С другой стороны те типы данных, которые подлежат обмену необходимо фильтровать с привязкой к подразделению. Например, данные о поступлении денег узла «Магазин 1 филиала 2» могут находиться только в узлах «Филиал 2», «Центр 1» и «Центр 2».

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

Также следует решить, на каком этапе своей жизни объект подлежит обмену. Например, обмену подлежат только проведенные расходные накладные, но никак не просто сохраненные. Либо Расходные накладные магазинов никогда не выгружаются из узла «Центр», даже после их корректировки, однако нужно учитывать обратный эффект - данные могут быть рассинхронизированы, либо какие-то изменения могут быть затерты.

Важно понимать - при обмене между узлами, какой-то из них является приоритетным. Рассмотрим ситуацию:

1. В узле «Магазин 1» создали документ;
2. При обмене он попал в узел «Филиал 1»;
3. Документ корректируется одновременно в обоих узлах.

Какой из документов будет считаться истинным? В 1С 8.х при использовании механизма «Планы обмена» по умолчанию приоритетным является главный узел, т.е. в данном случае изменения, сделанные в узле «Магазин 1» будут утеряны и заменены на данные из узла «Филиал 1».

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

Также немаловажно контролировать удаление объектов, иначе это может привести к тому, что, например, расходной накладной уже существовать не будет, а движения по бухгалтерскому учету останутся.

Механизмы обмена в 1С 8.х

Существуют два подхода для реализации:

1. Механизм «Планы обмена»;
2. Собственная реализация регистрации объектов.

Рассмотрим оба варианта.

Механизм планов обмена позволяет, без какой либо настройки, за несколько минут, создать РБД с полным обменом данными. Если установить флаг «Распределенная информационная база», то при создании пакета обновления будут выгружены и обновления конфигурации. Всего за несколько минут можно настроить и правила разрешения/запрета обмена различными типами данных, открыв состав плана обмена. Если установить флаг «Авторегистрация» в положение «Запретить», то данный тип объекта, без дополнительных усилий, никогда обмениваться не будет.

Зачем нужна регистрация, почему не выгружать все и сразу? В любом случае файл, содержащий только изменения состояния БД, будет меньше полного снимка самой БД. Поэтому вариант полной выгрузки рассматриваться не будет.

Как настроить фильтрацию данных по принадлежности к подразделению? Здесь уже придётся программировать. В моей реализации на запись любого объекта была установлена подписка на событие «При записи», где, посредством свойства «ОбменДанными.Получатели», можно установить список получателей данного объекта. Т.е. при выгрузке стандартными средствами для узла, которого нету в списке, объект выгружен не будет. Есть и другое решение - выбирать выгружать ли объект можно непосредственно при выгрузке объекта, в процедурах «ПриОтправкеДанныхПодчиненному» и «ПриОтправкеДанныхГлавному» модуля плана обмена.

Оба варианта имеют право на существование. Однако в качестве лучшего варианта выбрал первый, потому что вычисление признака выгружаемости происходит сразу же при записи объекта, что увеличивает длительность записи объекта на 3-5% (можно оптимизировать, в некоторых случаях можно досвести до 0.01%) т.е. в среднем 0.1-0.3 секунды, а в случае расчета выгружаемости объекта непосредственно при отправке данных, которая и так создает существенную нагрузку на БД, это время будет составлять до нескольких минут.

Для полного понимания работы механизма «Планы обмена» рекомендую прочитать главу 15 книги «Профессиональная разработка в система 1С:Предприятие 8», Габец А.П., Гончаров Д.И.

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

Транспорт

Задача транспортировки файлов от главного к подчиненному узлу сводиться к максимальной отказоустойчивости. Не редко файлы шифруются либо передаются по защищенному каналу. Для передачи файлов желательно использовать несколько различных служб, либо подготовить несколько различных вариантов подключения. Например, основной способ передачи - это используя FTP -сервер, подключенный через VPN -туннель; резервный - это e -mail сервер с TLS -подключением. Зачем нужен резервный канал с другой службой? Как показывает практика, использовать 2 различных FTP сервера менее надежно, чем FTP сервер и E -Mail .

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

Моя реализация РБД

Реализация полностью автономна, поэтому как подзадача выступала максимальная отказоустойчивость. Отсюда получилось 2 службы - служба транспорта обновлений и служба импорта/экспорта данных. Обе службы работают независимо друг от друга.

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

Для сокращения объема траффика xml -файлы упаковывались в zip -архивы. Система поддерживает два вида транспорта - FTP и E -mail .

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

Важно понимать, под каким системным пользователем будут работать службы, т.к. может не хватить прав на создание файлов даже во временной папке 1С. Для отладки крайне рекомендую писать каждую, успешно выполненную, операцию в журнал регистраций, либо в txt -файл. В 1С 8.1 выполнение серверного кода отладить нельзя.

Для удобства отладки и настройки своей реализации прикладываю обработку "Регистрация изменений", описание которой находится в самой обработке.

Общая схема работы комплекса обмена данными указана на рис 3.

Фильтрация данных происходит в подписке на событие «ПередЗаписью» каждого объекта. Не стоит забывать, что при создании начального образа узла данные тоже необходимо отфильтровать. Процедура создания начального образа довольно длительна, поэтому рекомендую оптимизировать по максимуму её код (например, кэшировать настройки фильтрации).

Послесловие

Главная задача - это ответить на список вопросов:

1. Зачем нам нужна РБД?
2. Чем не устраивает работа через RDP- клиент?
3. Где и почему мы хотим установить узлы РБД?
4. Как будет происходить транспорт обновлений?
5. Какой уровень отказоустойчивости будет реализован?

Обработка "РегистрацияИзменений"

Обработка позволяет принудительно регистрировать изменения в объектах. Есть несколько вариантов регистрации изменений:

1. Если установлена галочка на каком-либо метаданном и НЕ выбран ни единый объект и НЕ установлен флаг "Выгружать по всем значениям", то РЕГИСТРИРУЕТСЯ ТОЛЬКО ВЫБРАННАЯ ТАБЛИЦА;
2. Если установлен флаг "Выгружать по всем значениям", то выбранные метаданные будут выгружен по всем объектам в цикле;
3. Если переключатель установлен в режим "Выгружать только выбранные объекты", то буду выгружены исключительно выбранные объекты (например: установка флага на метаданном без выбора объектов равносильна включенному флагу "Выгружать по всем значениям" и переключателю в позиции "Выгружать только выбранные объекты";
4. Если переключатель установлен в режим "Выгружать выбранные и непосредственно связанные объекты" то буду выгружены выбранные объекты и те объекты, существование которых зависит от существования выбранного объекта(например: у справочников - подчиненные справочники);
5. Если переключатель установлен в режим "Выгружать по всем ссылкам", то буду выгружены ВСЕ объекты в которых присутствует ссылка на выбранный объект.

Из дополнительного функционала доступно:

• Перерегистрация зарегистрированных объектов, часто требуется для отладки;
• Удаление зарегистрированных, часто требуется для отладки;
• Печать изменений - печать полного перечня объектов, которые помечены как измененные;
• Печать дерева конфигурации - только для удобства просмотра всей конфигурации.

В этом материале подробная инструкция по настройке обмена РИБ для 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С Предприятия. Эти базы называют узлами распределенной информационной базы (далее просто узлы). Между этими узлами образован обмен информацией для синхронизации всех узлов (конфигураций и баз).

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

Базовые принципы работы РИБ

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

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

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

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

Прием и формирование сообщений обмена в РИБ устанавливаются одной командой

Планыобмена. ЗаписатьИзменения(ЗаписьСообщения, 0 )

Содержимое читается посредством команды

Вывод

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

Компоненту УРБД (Управление распределенными базами данных) применяют, когда необходимо обмениваться информацией между двумя идентичными информационными базами (далее – ИБ) по узкому каналу связи (например, модем, электронная почта). Ниже приведена пошаговая инструкция и практические советы по настройке УРБД в 1С:Предприятие 7.7. Пример приведен для двух ИБ, хотя настроить его на большее количество баз по аналогии с двумя базами не представляет большого труда.

1) За работу компоненты УРБД отвечает библиотека DistrDB.dll в папке BIN программы 1С:Предприятие. Эта компонента приобретается и устанавливается отдельно.

2) Для примера автообмена мы создадим две информационные базы, разместив их в папках с именами c:\1c_base1 и c:\1c_base2. Создайте эти папки, а в каждой из них – вложенные папки с именами CP и PC (латинскими буквами)

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

4) Закройте все окна в Конфигураторе и активизируйте пункт меню «Администрирование – Распределенная ИБ – Управление». Этот пункт меню доступен, если в папке BIN программы 1С:Предприятие имеется компонента DistrDB.dll. Если библиотека имеет неправильную версию или повреждена, просто переустановите 1С:Предприятие поверх текущей установки – библиотека DistrDB.dll будет замещена ее правильной версией.

5) В открывшемся окне нажмите кнопку «Центральная ИБ». В окне запроса укажите код новой информационной базы (укажите цифру 1) и ее описание (например, «Центральная ИБ»).

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

7) Нажмите кнопку «Новая периф. ИБ». В окне запроса укажите для нее код 2 и описание – «Периферийная ИБ».

8) Выделите однократным щелчком периферийную базу и нажмите кнопку «Настр. автообмена». В открывшемся окне установкой переключателя поменяйте «Ручной» режим автообмена на «Автоматический» и нажмите кнопку «ОК».

9) Нажмите кнопку «Выгрузить данные». Запомните (в буфер обмена) имя файла с выгрузкой «c:\1c_base1\CP\20.zip» - он нам еще пригодится. Нажмите ОК. По окончании выгрузки 1С напишет «Выгрузка успешно завершена».

10) Закройте Конфигуратор и войдите (также в режиме Конфигуратора) в папку (пока еще пустую), где должна лежать вторая ИБ (в нашем примере – c:\1c_base2). Укажите, что база должна быть в формате DBF/CDX и нажмите «ОК».

11) Зайдите в пункт меню Администрирование – Распределенная ИБ – Управление. В ответ на вопрос «Информационная база не обнаружена. Выполнить загрузку данных?» нажмите «Да» и укажите имя файла выгрузки (в нашем примере, «c:\1c_base1\CP\20.zip») и нажмите кнопку «ОК». По окончании загрузки 1С напишет «Загрузка успешно завершена». Мы успешно создали Периферийную ИБ, выгрузив данные из Центральной ИБ.

12) Измените что-нибудь (например, добавьте новый элемент справочника) в одной из информационных баз. Наша цель – добиться, чтобы изменения в одной (любой) ИБ попали в другую ИБ через автообмен. Используйте пункт меню «Администрирование» – «Распределенная ИБ» – «Автообмен» попеременно в каждой из баз. Вновь появляющиеся файлы выгрузок с расширением ZIP в папках CP и PC надо перемещать (копировать) между информационными базами по принципу CP->CP, PC->PC (в реальных «полевых» условиях обычно это делают при помощи электронной почты).

Советы и рецепты

1) Чтобы превратить распределенную базу в обычную, удалите файлы 1SDBSET.DBF, 1SDWNLDS.DBF, 1SUPDTS.DBF и соответствующие им файлы *.CDX, а также 1SSYSTEM.DBF. В принципе, достаточно удалить 1SSYSTEM.DBF. После этого необходимо восстановить точку актуальности, запустив программу в монопольном режиме. Этот трюк недокументирован (угадайте, почему), но, тем не менее, он работает.

2) Вы можете изменять конфигурацию 1С, но только в Центральной ИБ. Это очень удобно – изменения в периферийных ИБ «накатываются» автоматически.

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

4) Штатная возможность отправки почты в 1С реализована через интерфейс MAPI, когда взаимодействие происходит с почтовым клиентом (таким, как Outlook). Мой совет – не тратьте зря времени - с MAPI и разного рода Оутлюками на практике постоянно возникают заморочки, требующие «быстрой езды» разработчика между филиалами. Использовать прямое модемное соединение или FTP я не советую по этой же причине. Посылать почту лучше внешними компонентами, такими как rom-mail.dll или DialMail.dll.

Другой вариант - использовать CDO
http://avb1c.narod.ru/?=a9
(c) avb, Рупор абсурда

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

Если вы правильно настроите несколько констант (почтовые адреса, пароли, явки и т.д.), пользователю остается лишь дважды кликнуть на ярлык, чтобы запустить Автообмен.

Программа реализована как конфигурация 1С:Предприятие. Подробное описание содержится в приложенном файле DOC.

6) Если нужно автоматически выполнять дозвон до провайдера, используйте программу E-Type Dialer. Она умеет запускать внешние приложения при успешном соединении. Другой вариант – использовать внешнюю компоненту DialMail, которая имеет средства работы с модемом (совет – префикс «p» латинское перед номером дает импульсный набор, 9W перед номером – звонок через «девятку» и ожидание гудка в линии т.д.).

Замечание: в Windows XP есть встроенная звонилка rasdial.exe. Ключи командной строки:
rasdial.exe Элемент Пользователь Пароль
rasdial.exe Элемент /DISCONNECT

7) Приоритет отдается изменениям, выполненным в Центральной ИБ. Обратите внимание, что в типовых конфигурациях 1С применяются префиксы информационной базы (см. эту настройку в Константах), чтобы коды элементов справочников и номера документов, созданных в разных базах, не совпадали, и не нарушалась их уникальность.