Как сделать риб 1с

Добавил пользователь Алексей Ф.
Обновлено: 05.10.2024

На нашем сайте профессионалы делятся своим опытом и разработками. Вы получаете доступ к уникальному и самому полному хранилищу материалов для 1С, состоящему из более 30 000 отчетов, обработок, видео и т.д.

Рейтинг: 460

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

Проблемы 1С Расширения и 1С РИБа:

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

Но многие предпочитают делать отдельное расширение для каждого РИБа свое. Когда 1-2 РИБа еще можно внести изменения в каждое расширение, а когда их 10-15-20, то неудобно и затратно по времени.

Почему делают так? Чтобы избежать ошибок передачи самого расширения и данных. т.к. если в расширении указан признак "Используется в РИБ", то это расширение выгружается ВСЕГДА в файл обмена для узла, при каждой выгрузке (каждые 15 минут как правило). Даже если конфигурация расширения не изменялась не как, оно все равно будет выгружаться в файл обмена для распределенного узла. Это важно понимать: чем больше расширений или чем толще само расширение, тем толще и файл обмена при каждом обмене. Что может тянуть за собой разного рода проблемы.

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

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

Для исправления данной ситуации необходимо выполнить обновление справочника "Идентификаторы объектов расширений", делается это с помощью простой обработки (обработка приложена).

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

2. При обмене в центральным узлом, возникает ошибка получения данных в узле. Такая ошибка, как правило, возникает при добавлении нового расширения, наша любимая фирма 1С этот баг так и не исправила, как он был с самого начала 8.3.12, так он и есть по текущую платформу 8.3.19.1264 (хотя, может, так и задумано).

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

После чего получаем ошибку:
"Ошибка исключительной блокировки информационной базы
активные сеансы:
компьютер: RIB1"

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

Закрываем 1С предприятие, заходим в 1С конфигуратор, расширения нет. Заходим в 1С предприятие, делаем обмен, получаем ту же ошибку, и все по новой. Замкнутый круг. Расширение не принимается, и обмен перестает работать.

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

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

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

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

Немного отступления, был случай, который выпил много крови. Обновляли базу УТ 11.4 до последнего релиза в связи с маркировкой, обновили платформу т.к. новая УТ 11.4 не работала на той платформе, обновили РИБы (3 штуки) саму базу данных 1С и платформу соответственно. В базе было 2 расширения с доработками под нужды компании. Все работало все рады.

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

Ошибок по журналу нет, тесты базы через конфигуратор или через утилиту chdbfl проходят без ошибок, кэш не помогает, удаление расширений не помогает. Было ясно одно, что проблема с расширением, т.е. все работает, пока не трогаем расширение (восстанавливали неоднократно базу, пока не нашли причину). А причина была проста. Совместимость конфигурации была намного выше совместимости расширения, плюс ко всему платформа уже была 8.3.19. И проблемы в работе не было, т.е. 1С не выдавала ошибок совместимости или еще что-то, пока не поменяли структуру расширения, и тогда 1с очнулась, что вы нам тут втюхиваете. ушло 2 дня на поиски проблемы, а оказалось простая вещь.

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

4. Удаление расширения в центральном узле и распределенных базах. Если необходимо удалить расширение из базы, которое используется в распределенных базах, то его необходимо:

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

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

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

- Обязательно! Делаем копию БД (если что-то пойдет не так);
- Отключаем в распределенной базе центральный узел, это можно сделать с помощью обработки;

Также отключить подчиненный узел от главного узла можно с помощью параметра запуска конфигуратора /ResetMasterNode.
"C:\Program Files (x86)\1cv8\common\1cestart.exe" config /f "D:\1C\ПапкаБазы" /n администратор /p пароль /ResetMasterNode

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

- При первом входе в базу в режиме предприятия 1С спросит восстановить узел ВАЖНО его ВОССТАНОВИТЬ. ;

- После чего синхронизация проходит в штатном режиме.

5. Другие проблемы с расширениями. Прочие проблемы с расширениями при обмене.
- Нет доступа к файлу (если ранее все работало)
- файл не обнаружен Params\DBNames. и т.д.

Такие ошибки как правило возникают из-за зависшего кэша, и исправляются чисткой 1с КЭШа: "C:\Users\User\AppData\Local\1C\".

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

Для исправления данной ошибки требуется сделать следующие шаги:

- Обязательно! Делаем копию БД (если что-то пойдет не так);
- Выгружаем конфигурацию главного узла в файл *.cf в режиме конфигуратора.
- Отключаем в распределенной базе центральный узел, это можно сделать с помощью обработки;

Также отключить подчиненный узел от главного узла, можно с помощью параметра запуска конфигуратора /ResetMasterNode.
"C:\Program Files (x86)\1cv8\common\1cestart.exe" config /f "D:\1C\ПапкаБазы" /n администратор /p пароль /ResetMasterNode

Пример: "C:\Program Files (x86)\1cv8\8.3.19.1150\bin\1cv8.exe" config /ResetMasterNode

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

- Загружаем конфигурацию главного узла из файла *.cf в подчиненный узел в режиме конфигуратора. Загружаем полной заменой "Загрузить конфигурацию из файла", не сравнить, объединить конфигурации;

- При первом входе в базу в режиме предприятия 1С спросит восстановить узел ВАЖНО его ВОССТАНОВИТЬ. Либо восстановить главный узел можно с помощью обработки;

- После чего синхронизация проходит в штатном режиме.

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

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

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

Прочитав эту статью, вы:

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

Распределенная информационная база (РИБ)

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

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

Базу центрального офиса, где собираются все данные, называют центральной, а базы филиалов — периферийными.

Рассмотрим создание РИБ на примере 1С:Бухгалтерия 3.0.

Настройка центральной базы

Настройка РИБ выполняется в разделе Администрирование — Настройки программы —Синхронизация данных — ссылка Настройка синхронизации данных — кнопка Новая синхронизация данных — ссылка Распределенная информационная база .

Перед началом настройки выставляется префикс основной базы, например, ЦБ. PDF

Настройка центральной базы РИБ выполняется по этапам:

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

Результат выполненной настройки в центральной базе.

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

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

Настройка периферийной базы РИБ выполняется по этапам:

настройка параметров подключения; PDF
настройка правил отправки и получения данных.

Настройка выполняется Мастером настройки автоматически. Для настройки Сценария синхронизации нажмите кнопку Добавить и все правила будут созданы по умолчанию. PDF

Следуя шагам Мастера, завершите настройку.

Результат настройки периферийной базы.

После завершения настройки в периферийной базе проверьте наличие перенесенных данных из центральной базы:

настройки программы;
справочники;
документы;

Все данные должны присутствовать. Пример перенесенных поступлений. PDF

Обмен в РИБ

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

Будет выполнен обмен с центральной базой.

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

Аналогичные правила для центральной базы.

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

Причины возникновения ошибки

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

новое обновление центральной конфигурации до получения ответа о предыдущем обновлении периферийной конфигурации;
динамическое обновление центральной конфигурации;
отключение электропитания компьютера в момент обновления;
и т.д.

Обновление конфигурации центральной базы

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

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

Динамическое обновление

Конфигурация узла распределенной ИБ не соответствует ожидаемой.

Это предотвращает в большинстве случаев появление ошибки рассогласования конфигураций центральной и периферийных баз.

Но если по каким-то причинам ошибка все-таки имеет место — проблему нужно решать.

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

Отключение Главного узла периферийной базы

Данная методика неоднократно помогала нам решить проблему у клиентов при получении ошибки РИБ:

Конфигурация узла распределенной ИБ не соответствует ожидаемой.

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

При попытке обновить конфигурацию вручную команда Обновить конфигурацию недоступна.

Что делать? Рекомендуемая последовательность действий:

выгрузка конфигурации центральной базы (ЦБ) в файл;
открепление Главного узла в периферийной базе (ПБ);
обновление конфигурации в периферийной базе (ПБ);
закрепление Главного узла в периферийной базе (ПБ).

Выгрузка конфигурации ЦБ в файл

Откройте Конфигуратор ЦБ и выгрузите конфигурацию в файл по кнопке Конфигурация — Сохранить конфигурацию в файл .

Этим файлом мы обновим конфигурацию ПБ после открепления в ней Главного узла обмена.

Открепление Главного узла в ПБ

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

Код этой обработки невероятно прост, всего несколько строчек, и вы можете:

самостоятельно сделать такую обработку по указанному коду; PDF
скачать готовый вариант от БухЭксперт8.

Запустите обработку через Главное меню — Файл — Открыть .

Запуск выполняется пользователем с Полными правами или возможностью работать с внешними отчетами и обработками.

Будет открыта форма, указывающая на Главный узел ЦБ, в нашем случае БУХЭКСПЕРТ. Для отключения его нажмите на кнопку Отключить Главный узел .

При отключении Главного узла Конфигуратор ПБ должен быть закрыт.

Обновление конфигурации в ПБ

Откройте конфигуратор ПБ и убедитесь, что блокировка на обновление снята и команда обновить конфигурацию доступна: меню Конфигурация — Поддержка — Обновить конфигурацию . Тем не менее обновить конфигурацию ПБ выгруженным файлом конфигурации ЦБ на актуальных конфигурациях 1С не получится, для этого снимем с поддержки конфигурацию ПБ, а потом вернем ее при загрузке файла конфигурации ЦБ: меню Конфигурация — Поддержка — Настройки поддержки — кнопка Снять с поддержки .

Загрузите файл конфигурации ЦБ: меню Конфигурация — Загрузить конфигурацию из файла .

Примите обновление конфигурации по кнопке F7.

Главный результат операции в сопоставлении редакций ЦБ и ПФ. Они должны быть одинаковыми. Проверить после обновления редакцию ПБ можно по меню Справка — О программе .

Подключение Главного узла в ПБ

Откройте ПБ в пользовательском режиме. На актуальных релизах 1С программа автоматически видит отключенный Главный узел и предлагает его восстановить. Нажимаете кнопку Восстановить .

Программа выполнит автоматическое обновление базы данных.

Если программа 1С не предлагает автоматически восстановить подключение к Главному узлу или по каким-то причинам она проходит с ошибками, запустите внешнюю обработку Главный узел : кнопка Главное меню — Файл — Открыть . Запуск выполняется пользователем с Полными правами или возможностью работать с внешними отчетами и обработками.

В открывшейся форме в поле Главный узел базы укажите тип данных Полный.

Выберите из списка узлов главный, в нашем случае БУХЭКСПЕРТ, и нажмите кнопку Подключить Главный узел .

При подключении Главного узла Конфигуратор ПБ должен быть закрыт.

Выполните обмен сначала в ПБ, а после него в ЦБ. Все изменения должны загрузиться.

Корректировка файлов обмена РИБ

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

выгрузка файла обмена из периферийной базы;
выгрузка файла обмена из центральной базы;
корректировка файла обмена из ЦБ;
загрузка скорректированного файла;
перезапись файла обмена из ПБ;
проверка исправлений.

Выгрузка файла обмена из периферийной базы

Оставьте рабочим только выполняемое действие настройки Отправка данных , используя кнопку Настроить — Сценарии синхронизации — кнопка Включить/Отключить .

Выполните обмен с центральной базой по кнопке Выполнить сценарий .

Выгрузка файла обмена из центральной базы

Выполните отправку данных из центральной базы по кнопке Выполнить сценарий .

Корректировка файла обмена из ЦБ

В файле обмена из ЦБ замените блок, содержащий информацию об изменениях конфигурации на блок из файла ПБ.

Файлы обмена находятся в папке, которую указали при настройке обмена синхронизации распределенных баз. Всего там находятся два файла:

Файл выгрузки из периферийной базы: Message_ФЛ_ЦБ.
Файл выгрузки из центральной базы: Message_ЦБ_ФЛ.

Откройте файл обмена Message_ЦБ_ФЛ, редактором позволяющим редактировать xml-файлы, например, Блокнот.

В файле Message_ЦБ_ФЛ блок Загрузка скорректированного файла

Конфигуратор при получении данных должен быть закрыт.

После этого делаем Отправку данных и переходим в центральную базу.

Проверка обмена в центральной базой

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

Да, все отлично. Обмен восстановлен, ошибка исправлена.

Работа с ошибками РИБ относится к разряду профессиональных и Бухэксперт8 рекомендует передавать их для исправления специалистам 1С. При работе с ошибками обязательно копируйте базы данных.

Помогла статья?

Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно

Карточка публикации

(2 оценок, среднее: 5,00 из 5)

Данную публикацию можно обсудить в комментариях ниже.
Обратите внимание! В комментариях наши кураторы не отвечают на вопросы по программам 1С и законодательству.
Задать вопрос нашим специалистам можно по ссылке >>

Приветствую Вас, уважаемый читатель нашего блога SoftMaker.kz! Часто бухгалтеру необходимо забирать работу домой, а так же базу 1С:Предприятие 8. Кто-то решает взять файл базы домой, поработать и принести назад на работу. Ну а что, если на работе в этой базе будет работать другой сотрудник? Тогда, если переписать базу из дома на рабочий компьютер, все данные сделанные на работе будут удалены. Как сделать, чтобы все данные в обоих базах были сохранены? Давайте посмотрим!

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

Подготовка к обмену

Для создания обмена между двумя идентичными базами мы будем использовать распределенную информационную базу (РИБ). Давайте запустим систему 1С8 в режиме 1С:Предприятие.

После записи образа, откройте список баз, нажав на ярлык 1С:Предприятие 8.

Выполнение обмена

Выполнение обмена происходит так:

Если Вы в домашней базе, то нужно Зайти в офисную базу и проделать тоже самое:

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

Если так не делать, то выгрузка выдаст ошибку.

Способы обмена

Для работы с распределенной базой используйте один из следующих способов:

И самое важное, обмен должен осуществляется через общую папку. Если мы пользуемся первым способом, то на офисном компьютере это путь, например: D:\ОбменИзОфисаДомой, поэтому важно, чтобы в домашней базе, в плане обмена был указан этот путь D:\ОбменИзОфисаДомой.

Если мы пользуемся вторым способом, то на ноутбуке это путь, например: Z:\ОбменИзОфисаДомой. Важно, чтобы из ноутбука он был виден и в домашней базе. В плане обмена должен быть указан этот путь Z:\ОбменИзОфисаДомой.

Если у Вас к этой папке другой путь, то его можно изменить в плане обмена:

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

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

SQL Express 2008 R2 - последняя на текущий момент времени версия данной линейки SQL Server.
Ограничния:
- 2 ГБ ОЗУ
- 1 физический процессор
- 10 ГБ максимальный объём базы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также: