Resetmasternode как пользоваться

Записки IT специалиста

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

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

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

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

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

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

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

Откройте командную строку и введите (с учетом версии платформы и реального пути установки):

"C:\Program Files (x86)\1cv8\8.3.6.2100\bin\1cv8.exe" config /ResetMasterNode

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

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

Внимание! На платформах 8.3.7 — 8.3.9 выполнение данной команды приводит к аварийному завершению работы. Ошибка исправлена в платформе 8.3.10.

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

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

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

Затем в периферийном узле запускаем ИБ (предварительно отключив ее от главного узла) в Конфигураторе и снимаем с поддержки. Для этого выбираем: Конфигурация — Поддержка — Настройка поддержки.

В открывшемся окне сначала включаем возможности изменения.

А затем снимаем конфигурацию с поддержки.

Теперь можно загружать конфигурацию из файла, для этого выберите Конфигурация — Загрузить конфигурацию из файла и укажите не переданный из центрального узла cf-файл. После чего вы получите предупреждение о том, что текущая конфигурация не пустая. Обращаем ваше внимание, что проделываемые нами манипуляции потенциально опасны и могут привести к необратимому повреждению ИБ, поэтому перед тем, как продолжать убедитесь, что у вас есть актуальная резервная копия.

Ждем окончания загрузки конфигурации и обязательно обновляем конфигурацию базы данных.

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

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

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Разделение базы по организациям: Бухгалтерия для Украины 2.0

Задача: в информационной базе (Бухгалтерия для Украины 2.0) ведется несколько предприятий. Принято решение разделить их и вести учет отдельно. Необходимо вынести одно предприятие в отдельную базу для продолжения работы в ней.

Для решения этой задачи есть несколько методов.

Метод 1. Разделение бухгалтерской базы по предприятиям с помощью РИБ

В примере рассматривается конфигурация «Бухгалтерия для Украины 2.0«. Однако, полагаю, данное решение подойдет к большинству современных конфигураций на базе управляемого приложения.

Включаем синхронизацию данных

Для этого переходим в раздел «Администрирование» -> «Настройки синхронизации данных«:

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

Добавляем синхронизацию данных «Распределенная информационная база с фильтром по организации«:

На следующем шаге указываем любой каталог:

Пропустив настройку FTP и e-mail переходим к указанию одной или нескольких организаций, которые мы будем переносить. Обязательно указываем префикс инфобазы.

Пропускаем страницу настроек и переходим к созданию образа РИБ:

Указываем каталог, в котором будет создана новая информационная база (в примере D:\tmp\Бух20-риб\):

После создания образа выйдет такое сообщение:

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

Выполняем отключение главного узла в новой базе

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

После первого старта новой базы запускается окно настройки синхронизации. Нажмем «Отмена» и «Да» и настройки синхронизации БД заполнятся по-умолчанию:

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

Если далее просто запустить базу и согласиться на отключение от главного узла, мы получим ошибку (касается редакции Бухгалтерия для Украины 2.0.13.1 и, вероятно, некоторых других):

Платформа: 1С:Предприятие 8.3 (8.3.12.1790) Конфигурация: Бухгалтерия для Украины, редакция 2.0. (2.0.13.1) (http://1c.ua/v8/RegionalSolutions_UA_BUH.php) Copyright © Molenari OU, 2017-2018. All rights reserved Режим: Файловый (без сжатия) Приложение: Тонкий клиент Локализация: Информационная база: украинский (Украина), Сеанс: русский (Россия) Вариант интерфейса: Такси Ошибки: -------------------------------------------------------------------------------- 15.02.2019 15:53:52 У пользователя недостаточно прав на исполнение операции над базой данных. объект: 'Справочник.ПараметрыСинхронизацииV77'; право: 'Удаление' Таблица: 'RefSInf9672', SDBL-команда: 'DELETE'.

Чтобы избежать ее, необходимо добавить право «Удаление» справочника «ПараметрыСинхронизацииV77» для роли «Полные права«. Для этого включаем возможность изменения в базе:

И добавляем нужно нам право:

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

Константа «Настройка подчиненного узла РИБ завершена» — флаг должен быть снят

Константа «Это автономное рабочее место» — флаг должен быть снят.

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

Очистка от лишних данных

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

Для устранения необходимо запустить Тестирование и исправление информационной базы из под конфигуратора с указанием настройки «Очищать ссылки»:

Проверка

Для проверки корректности переноса сформируем ОСВ в базе-источнике и базе-приемнике и убедимся что они сходятся:

Плюсы и минусы разделения с помощью РИБ

К плюсам переноса с помощью РИБ можно отнести высокую скорость и относительную простоту процесса.

Минусы: элементы справочников переносятся не все присутсвующие в БД, а только те что используются в документах по организации. Для примера, можно привести справочник «Контрагенты«:

Метод 2. Разделения по организациям с помощью инструментов разработчика

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

Подготовка базы

Сначала сделаем копию нашей базы. Для работы будем использовать портативную версию инструментов разработчиков. Необходимо отключить «Защиту от опасных действий» в настройках пользователя в конфигураторе:

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

Удаление «лишних» организаций

Открываем обработку инструменты разработчика портативный и запускаем обычное приложение (панель инструментов работает только в этом режиме):

Помечаем «лишние» организации на удаление:

В панели разработчика запускаем инструмент «Удаление объектов с контролем ссылок» и указываем что планируем работать со справочником «Организации«:

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

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

В качестве первого шага, необходимо добавить все элементы, ссылающиеся на наших кандидатов, в список кандидатов на удаление. Для этого уберем отбор «По кандидату«, выделим все элементы нижней таб. части (Ctrl+A), нажмем «В кандидаты«. От пометки удаления лучше отказаться (при ошибке установки пометки удаления процесс будет прекращен).

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

Банковские счета

Удалить банковский счет по организации «Добро» мешают 4 ссылки на приходные кассовые ордера:

Каждый из них можно открыть и просмотреть с помощью двойного клика на колонку «Объект«:

Как ни странно, но документ организации «Пилот» визуально не содержит ссылок на р/сч организации «Добро«. Для поиска ссылки воспользуемся еще одним удобным инструментом «Редактор объекта БД«, который можно вызвать с помощью кнопки «Редактировать«. По клику открывается окно редактора объекта БД и в нём подсвечивается найденная ссылка.

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

Подразделения организаций

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

Справочник «Файлы»

У организации «Добро» в БД присутствуют 2 хранимых файла. Эти файлы присутствуют в кандидатах на удаление, но на них ссылаются элементы справочника «Версии файлов«. Попробуем открыть элемент справочника и пометить его на удаление вручную (это также можно сделать через добавление в кандидаты с установкой пометки удаления):

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

Контрагенты

У контрагентов есть реквизит «Основной договор«, который ссылается на договор с одной из удаляемых организаций. Следовательно, необходимо очистить ссылку на основной договор у таких контрагентов. Для этого наиболее удобным будет инструмент «Консоль запросов«. В нем мы можем задать запрос к БД и на вкладке «Обработка строки результата» указать программный код, который будет выполнен для каждой полученной строки результата запроса.

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

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

Объект = СтрокаРезультата.Ссылка.ПолучитьОбъект(); // Обработка объекта Объект.ОсновнойДоговорКонтрагента = Справочники.ДоговорыКонтрагентов.ПустаяСсылка(); //Объект.ОбменДанными.Загрузка = Истина; Объект.Записать();

Документ «Установка цен номенклатуры»

В списке документов, препятсвующих удалению, присутствует «Установка цен номенклатуры«. С помощью редактора объекта БД найден ссылку на организацию:

Ссылка на организацию «ПП Петренко» присутствует в последовательности «Документы организаций«. Инструмент «Редактор объекта БД» позволяет редактировать не только реквизиты объекта, но и движения документа. Удалим движение и запишем объект помощью кнопки «Записать движения«.

Справочник «Зарплатные проекты»

На зарплатные проекты ссылаются элементы регистра сведений «Лицевые счета сотрудников по зарплатным проектам«:

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

Другие ссылки на регистры сведений

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

Тестирование и исправление БД

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

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

Плюсы:

1. Полный контроль над процессом;
2. Справочники номенклатура, контрагенты и пр. полностью перенесены.

Минусы:

1. Полуручная работа;
2. Требует программирования.

«РИБ в 1С простыми словами» и «Как подчиненную базу 1С сделать самостоятельной»

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

Вот посмотрим на картинку из первой ссылки по запросу в Яндексе:

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

Визуализируем:

У нас большая компания и много филиалов. Есть доработанная УНФ, которую мы гордо называем УБФ(Управление Большой Фирмой). Но мы решили, что хватит терпеть то, что все филиалы имеют доступ к документам всех филиалов и каждому филиалу решили сделать отдельную базу, которую синхронизировать с нашей основной базой для передачи данных. Что ж, можно. Сделали.

И внезапно мы решили изменить картинку, которая появляется при входе в базу, захотели поместить туда логотип нашей фирмы, а почему бы и нет?

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

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

Как создать подчиненную базу, на пальцах:

я буду использовать Управление торговлей, редакция 11 (11.4.13.275), но способ, в целом, одинаковый во всех типовых конфигурациях.

1) Сначала проделаем шаги, как при настройке обычной синхронизации:

2) . поставим галочку, нажмем.

4) тут ознакомимся с описанием. Я выберу обычную настройку, но если бы мы следовали примеру выше, то нужно было бы выбрать «с фильтром» и там одним кликом выбрать нужный филиал.

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

6) Указываем префикс — он будет подставляться к номерам документов, чтобы можно было отличить документы дочки и основной базы.

7) в общем случае, тут ничего не надо нажимать, кроме «Записать и закрыть».

8) А вот теперь создаем нашу новую подчиненную базу:

9) указываем место, куда ее покладем.

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

(обратите внимание на верхний левый угол окна программы, там название базы, он отличается от предыдущих, так как это «дочка»)

Кстати, в новой базе все пользователи будут выключены, пароли сброшены, нужно включить руками:

В общем-то ВСЕ.

Подчиненная база создана!

Теперь, когда наши программисты что-нибудь улучшат, эти улучшения прилетят в подчиненные базы сами.

Вот что-то изменили в основной базе:

нам нужно перенести изменения в базы-дочки.

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

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

После нажатия на Далее база закроется и начнет устанавливать обновления.

Когда обновы установятся, база начнет запускаться и сообщит нам следующее:

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

Откроем конфигурацию и вот что увидим

Нажмем на «Обновить конфигурацию базы данных».

Увидим список изменений, которые прилетели с обновлениями:

И вот эти обновления появились в подчиненной базе.

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

Несколько правил:

1) Все узлы, кроме одного, должны иметь по одному главному узлу и один узел не будет иметь главного узла — это корневой узел.

2) Конфигурация может быть изменена только в узле, не имеющем главного узла (то есть в корневом).

3) Изменения конфигурации будут передаваться от главного к подчиненным узлам.

4) Разрешение коллизий так же будет производиться исходя из отношений «главный — подчиненный» — если изменения сделаны одновременно и в главном и в подчиненном узлах, то приняты будут изменения главного узла.

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

А теперь то, ради чего все писалось.

Как подчиненную базу сделать обычной(нормальной, отдельной, как хотите).

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

1) Заходим в свойства ярлыка запуска окна 1С:Предприятие:

2) В поле «Объект» дописываем:

DESIGNER /F»Путь до базы» /N»Имя Пользователя в базе» /P»Пароль пользователя» /ResetMasterNode

В итоге у меня получится:

«C:\Program Files\1cv8\common\1cestart.exe» DESIGNER /F»C:\Users\79119\Desktop\РИБ» /N»» /P»» /ResetMasterNode

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

3) Сохраняем изменения в ярлыке и запускаем его.

4) Не забываем удалить добавленный текст из ярлыка.

5) Готово 🙂 при запуске база сообщит:

Кликаем «Отключить» — база теперь самостоятельная!

Вот и все! Успехов хорошим людям желаю! Спасибо!

• 1с
• риб
• распределённые базы данных
• распределенные базы данных

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

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

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

1. Отключение режима распределенной информационной базы.

Выполнить отключение информационной базы можно с помощью параметра запуска конфигуратора /ResetMasterNode.

2. Подтверждение отключения связи с главным узлом.

Данный этап осуществляется при входе в базу через режим «Конфигуратор».

3. Действия над служебными данными.

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

Через меню «Все функции» — «Константы» выполнить установку служебных констант:

Настройка подчиненного узла РИБ завершена — флаг должен быть снят.

Это автономное рабочее место — флаг должен быть снят.

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

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

Логунова Яна
Консультант Компании «АНТ-ХИЛЛ»
При цитировании статей или заметок
ссылка на сайт автора обязательна
Накопились вопросы и нужна помощь?
С удовольствием на все ответим и поможем всё настроить!
звоните!

(473) 202-20-10 (495) 145-94-84

© 2023 1С-ФРАНЧАЙЗИ
НАШИ СОЦСЕТИ

• БУХГАЛТЕРСКИЙ УЧЕТ
• CRM
• ДОКУМЕНТООБОРОТ
• РЕСТОРАНЫ И ГОСТИНИЦЫ
• МАРКИРОВКА

Г. ВОРОНЕЖ,
БУЛЬВАР ПОБЕДЫ, 50