1с бухгалтерия риб. Алексей алексеев добро пожаловать в мой уютненький бложек. Формирование пакетов обновлений

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

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

Задачи РБД

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

  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.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С:Предприятие 7.7. Пример приведен для двух ИБ, хотя настроить его на большее количество баз по аналогии с двумя базами не составляет большого труда. Автор статьи: romix | Редакторы: evGenius
Последняя редакция №7 от 22.02.08 | История
URL:

Ключевые слова: УРБД, скрипт для автообмена, обмен между филиалами, почта, rom-mail.dll, DialMail.dll, CDO, дозвон, УРИБ

Компоненту УРБД (Управление распределенными базами данных) применяют, когда необходимо обмениваться информацией между двумя идентичными информационными базами (далее – ИБ) по узкому каналу связи (например, модем, электронная почта). Ниже приведена пошаговая инструкция и практические советы по настройке УРБД в 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С применяются префиксы информационной базы (см. эту настройку в Константах), чтобы коды элементов справочников и номера документов, созданных в разных базах, не совпадали, и не нарушалась их уникальность.

В данной статье речь пойдет о настройке распределенной базы данных 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 в комментарии!

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

Примером служит конфигурация Управление Торговлей 11 (11.0.6.9) — платформа 1С 8.2.

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

  1. Первое что мы делаем, это запускаем 1С:Предприятие, затем переходим на вкладку "Администрирование" и в конечном итоге выбираем пункт "Настройка параметров учета".
  2. После этого откроется окно и уже в нем выбираем пункт "Обмен данными". Нажимаем на разрешение использования обмена данными, и после этого нажимаем кнопку "Записать и закрыть".
  3. После того как включим обмены данными, в левой части окна должен появится новый пункт "Обмен данными". Кликаем по пункту "Обмен данными".
  4. Когда откроется окно, кликаем на кнопку "Создать". Выбираем пункт "Создать обмен в распределенной информационной базе" После этого откроется окно мастера по созданию Распределительно Информационной Базы.
  5. Ищем в открывшемся окне кнопку "Далее" и нажимаем на нее, после этого переходим к другому окну. В проссматриваемой Вами статье изображен обмен данными через локальный или сетевой каталог.
  6. Находим каталог обмена, ставим галочку напротив пункта "Сжимать файл исходящего сообщения". Затем нажимаем на "Далее" и пропускаем два следующих окна (делаем это потому что в этой статье не будем рассматривать обмен через FTP и почту).
  7. Жмем "Далее".
  8. Называем как Вам удобно имя для плана обмена данными, я выбрала, например, "Обмен_С_Периферийной_Базой", Вы можете установить свое имя. Затем проверяем что бы "Основной способ обмена данными" был "Обмен через локальный или сетевой каталог" и нажимаем "Далее".
  9. После того как проверим содержимое текущего окна и нажимаем "Далее".
  10. В данном окне также ничего не меняем и нажимаем кнопку "Готово".
  11. Указываем путь к папке для создания Распределительно Информационной Базы. Указывать нужно в формате UNC, например "\\rib\1Cv8.1CD". Если все правильно — то в указанной папке создастся файл распределенной базы данных.
  12. Теперь настраиваем автообмен и его расписание. Для этого переходим на вкладку "Администрирование" и выбираем пункт "Обмен данными" и делаем двойной клик по существующей строке в списке обменов данными:
  13. В открывшемся окне кликаем по "Сценарии обменов данными":
  14. В открывшемся окне нажимаем на кнопку "Добавить":
  15. В открывшемся окне кликаем по строке "Каждый день, каждые 900 сек.":
  16. В открывшемся окне устанавливаем нужные параметры:
  17. Устанавливаем такие параметры, чтобы обмен выполнялся ежедневно с 00:00:00 по 23:59:59 с перерывом в 30 секунд. Это делается для того, что бы показать, что обмен выполняется в прилагаемом видеоролике, вы можете установить у себя другие значения параметров. В предыдущем окне нажимаем на кнопку"OK" и "Записать и закрыть".
  18. Завершена настройка обмена данными для центрального узла, аналогично производится настройка периферийного узла. Необходимо изменить ярлык запуска 1С, добавив параметр запуска "/CDoScheduledJobs" для того, что бы обмен выполнялся в автоматическом режиме.
Настройка автоматического обмена на периферийном узле ничем не отличается от настройки на главном узле. Если настраивать сценарий обмена, то обмен будет запускаться автоматически при входе пользователя с правами админа.

Конфигурация в распределенке обновляется так: вручную, сначала изменения делаются в ЦБ, потом делаем выгрузку и несем в периферийку. Автоматом, обычно, не срабатывает обмен.