1с 8 уриб не выгружаются пользователи
Создание и настройка распределенной базы данных (РИБ) в 1С 8.3 Бухгалтерия (и других конфигурациях) необходимы в случаях, когда нет возможности работать нескольким пользователям, одновременно подключаясь к одной базе данных. В настоящее время это довольно редкое явление, так как прекрасно работает стандартный удаленный рабочий стол и есть другие программы, которые обеспечивают удаленное подключение к центральному компьютеру, где расположена база данных.
Но тем не менее бывают ситуации, когда просто-напросто нет интернета. А данные должны в итоге оказаться в одной информационной базе. Для этого и создается распределенная база данных.
Обычно главную базу называют центральной, а остальные — периферийными. Суть в том, что либо в ручном, либо в автоматическом режиме (зависит от настройки) базы данных объединяются в одну. Чтобы номера вновь введенных документов и коды справочников не дублировались, каждой базе данных назначается префикс.
В этой инструкции мы на примере создадим центральную и периферийную базы данных, проверим обмен между ними. Это пособие подойдет как для 1С 8.3 Бухгалтерия, так и для 1С Управление торговлей (УТ) и других конфигураций.
Настройка главной (центральной) распределенной базы РИБ
Зайдем в меню 1С «Администрирование», далее по ссылке «Настройки синхронизации данных». В открывшемся окне нужно установить флажок «Синхронизация данных». Станет активной ссылка «Синхронизация данных». Сразу здесь же установим префикс для главной информационной базы – например, «ЦБ»:
Заходим по ссылке «Синхронизация данных», откроется окно с кнопкой «Настроить синхронизацию данных». При нажатии на эту кнопку откроется выпадающий список, где нужно выбрать режим «Полный». Если требуется синхронизация только по одной организации, нужно выбрать «По организации…».
В следующем окне нам программа предложит сделать резервную копию. Настоятельно рекомендую сделать это, так как следующие шаги настройки могут быть необратимы.
После создания резервной копии нажимаем кнопку «Далее». На следующем шаге нам следует определиться, как будет происходить синхронизация:
- через локальный каталог или каталог в локальной сети;
- по интернету посредством FTP.
Для простоты и наглядности примера выберем локальный каталог. Я указал следующий путь: «D:\Базы 1С\Синхронизация». Не лишней будет проверка записи в данный каталог, для этого есть специальная кнопка:
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
Получите понятные самоучители по 1С бесплатно:
Следующие шаги с настройкой синхронизации по FTP и электронной почте пропускаем. Останавливаемся на настройках названий главной и периферийной баз данных. Здесь же зададим префикс для периферийной базы:
Не забывайте, что префиксы каждой базы должны быть уникальны. В противном случае Вы получите ошибку «Значение префикса первой информационной базы не уникально».
Жмем «Далее», проверяем введенную информацию и опять нажимаем «Далее», затем — «Готово». В поле «Полное имя файловой базы» указываем файл 1Cv8.1CD в каталоге, который создали для синхронизации. Создаем начальный образ распределенной базы 1С:
После создания начального образа РИБ в 1С можно задать расписание синхронизации или синхронизировать вручную:
После синхронизации можно подключиться к новой базе данных и убедиться, что туда выгрузилась информация из центральной базы:
Только сразу в новой периферийной базе заведите хотя бы одного пользователя с правами Администратора.
Настройка синхронизации в периферийной базе данных
В периферийной базе 1С настройка намного проще. Достаточно установить флажок «Синхронизация данных» и перейти по одноименной ссылке. И мы почти сразу попадаем в окно с кнопкой «Синхронизировать». Попробуем создать тестовую номенклатуру в периферийной базе и выгрузить ее в основную с помощью РИБ:
Как видно, идет полноценный двухсторонний обмен информации с префиксами информационных баз.
В заключение хочется добавить важное замечание. Изменения в конфигурации можно производить только в центральной базе данных. Эти изменения потом автоматически будут транслированы в периферийные базы.
В заключение рекомендуем видеоинструкцию по настройке РИБ в 1С на примере Управление Торговлей:
Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):
1. Конфигурация узла распределенной ИБ не соответствует ожидаемой.
Самой распространенной ошибкой при использовании распределенных баз в 1с:Предприятие 8.x является ошибка "Конфигурация узла распределенной ИБ не соответствует ожидаемой". Связана она с рассинхронизацией конфигурации главного и подчиненного узла, возникать может по нескольким причинам, самая распространенная из них это динамическое обновление конфигурации. Рассмотрим основные пути решения данной проблемы, укажу способы по простоте их использования, сначала самые простые (но иногда не менее эффективные), потом более сложные:
Чистка кэша .
- При работе в режиме предприятия 1с кэширует метаданные для ускорения работы программы и при динамическом обновлении конфигурации использует их до момента перезапуска сеанса пользователя. При это могут возникать ситуации, когда после перезапуска программа не обновила метаданные из измененной, а продолжает использовать старые. В такой ситуации помогает очистка кэша, при новом запуске программа обновит метаданные. Очистить кэш можно множеством способов, приведу несколько из них:
- На мой взгляд самый простой из них это удаление базы из списка информационных баз и добавление заново под другим именем. При добавлении базы как новой в список информационных баз программа создаст новый каталог на диски для хранения кэшей к этой базе.
- Можно очистить базу удалив папки с кэшем. Папки храняться в зависимости от версии windows:
\Local Settings\Application Data\1C\1Cv82
Можно воспользоваться готовым bat-файлом для удаление файлов кэша, как это описано в этой статье "Чистка кэша 1с".
Не денамическое обновление корневого узла.
- Данный метод обноружил случайно, на просторах интернета такого способа не нашел, но помогает он очень часто и в отличии от следующих способов помогает решить проблему намного быстрее и проще. Заключается он в том, что мы еще раз меняем что либо в корне конфигурации (я чаще всего меняю синоним конфигурации, например добаляя пробел в конце синонима) и делаем при этом не динамическое обновление. После этого производим еще раз обмен из главного узла с подчиненными. В большенстве случаев, хотя и не всегда к сожалению, данный метод позволяет решить ошибку рассинхронизации конфигураций. Этот способ не всегда является эффективным, но в отличии от следующих способов позволяет быстро решить данную проблему, особенно при большом количестве узлов распределенных баз.
Перенос конфигурации в распределенный узел .
Самый распространенный способ решения данной проблемы, он почти в 100% случаев помогает решить данную проблему, опять таки замечу, что почти в 100%, т.к. у меня возникали случаи, когда переносом конфигурации из главного узла в подчиненный проблема не решалась. Данный метод заключается в переносе конфигурации из главной базы в распределенную.
Последовательность действий:
- выгружаем из центральной базы конфигурацию в cf-файл;
- отвязываем переферийную базу от главного узла, вызвав команду:
- заменяем конфигурацию переферийной базы на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла".
- Привязываем переферийную базу обратно к главному узлу РИБ, вызвав команду:
где в качестве параметра передаем главный узел распределенной базы.
Для выполнение этих действий удобнее всего воспользоваться обработкой, которую можно скачать здесь (подходит для всех конфигураций на не управляемых формах, т.к. Розница 1.0 или УТ 10.3, огромное множество аналогичных можно найти на просторах инфостарта).
Подмена хэша конфигурации в файле обмена.
- Данный метод был взят из статьи Популярные ошибки РИБ. Метод на мой взгляд довольно таки сложный и длительный, поэтому я его указываю как самый последний из вариантов решения данной проблемы, его стоит использовать только лишь в том случае, если не один из выше перечисленных способов не позволил решить проблему. Его суть заключается в том, что мы заменяем хеш конфигурации в файле обмена на правильный и тем самым обманывая программу производим обмен.
Последовательность действий:
- выполняем действия из предыдущей методики;
- выгружаем из переферийной базы файл обмена, но не загружаем его в главную базу;
- выгружаем из главной базы файл обмена, но не загружаем его в переферийную базу;
- в файле обмена из главной базы заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла переферийной базы (пример см. ниже).
- производим загрузку файла из 4-го пункта в переферийную базу;
- обязательно перезаписываем файл обмена из переферийной базы (2-й пункт) этот файл не должен быть загружен при обмене в главную базу.
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из главной базы:
нужно заменить на блок файла обмена из переферийной базы (обратите внимание Digest1 у файла из переферийной базы всегда равен "00000000000000000000000000000000". )
3. Ошибка преобразования данных XML.
Как и большинство феодальных дистрибьюторских бизнесов, все начиналось с одной-единственной базы УТ.
Далее, как говорится, шли годы, компания росла, добавлялись новые филиалы - количество которых приблизилось к 30-ти, а потом и превысило это количество, к тому же разрастались процессы и запросы к актуальности данных. Продолжительность полного цикла обмена между 30 базами РИБ с большим количеством документов не отвечала требованиям бизнеса и многие данные должны были появляться «здесь и сейчас».
Центральная база не успевала отработать весь объем, блокировала работу и, как следствие, была выделена только для обмена, т.к работа в ней пользователей была невозможна. Сделали так, что центральная база (ЦБ) превратилась в периферийную, а обменная база (ОБ) стала главным узлом. Так как в качестве транспорта данных использовался FTP и в схему передачи данных добавилось ещё одно звено ОБ, то при этом значительно увеличилось время для передачи данных от ЦБ до филиала: до 6 часов. А такие вещи как скидки, например, или установку цен номенклатуры, очень хотелось, да собственно прямо скажем - требовалось - передавать побыстрее. Приоритезация решалась последовательностью обмена с ОБ (сначала ЦБ, потом остальные).
Любые срочные динамические изменения приводили к полному циклу обмена. Без фундаментальных изменений логики информационных потоков возможность получить актуальную информацию или впоследствии сопоставить дубли не представлялось возможным.
В качестве экспериментов были испробованы различные методы оптимизации скорости обмена. Были включены урезанные планы обмена для миграции выборочных типов объектов, однако этот подход не оправдал себя из-за низкой пропускной способности центральной базы. Регламенты не всегда можно было выстроить последовательно и без накладок. Низкая масштабируемость решения (каждый раз создавать отдельный план) наводила на мысли о неверном пути.
Дополнительно были изучены возможности работы по правилам обмена, но поддержка правил тоже требовала ресурсов, причем полученная производительность не превышала скорости типового обмена. Работа с правилами порождала значительное число новых вопросов, и которые в итоге не позволили выбрать данное решение.
Эпоха веб сервисов
Думаем. думаем. и придумываем
Технология веб-сервисов зарекомендовала себя с хорошей стороны и возникла шальная мысль:
«А не перевести ли весь обмен на веб-сервисы? Базы все однотипные (модное слово “не гетерогенные”), будет работать сериализация, напилим базу-диспетчер обмена и будет нам счастье».
Что получаем в итоге: обмен будет пообъектный, регистрация хранится в плане обмена, при выгрузке объект переносим в буфер до подтверждения получения данных в приемнике.
На первый взгляд звучит заманчиво, но надо решить некоторые вопросы, а именно:
1. Изменения конфигурации
Как их будем передавать? Не очень хочется городить пакетные обновления со своим управлением. Ну ок, отдадим эту задачу на типовой РИБ, пусть меняет штатными средствами по расписанию.
2. Приоритезация изменений
В базе-диспетчере (БДО) есть приоритет (число) для каждого филиала. Если пришел объект в БДО с более высоким приоритетом, то он перезаписывается в раздаче для получателей. Перед загрузкой в более приоритетную базу проверяем наличие изменений в плане объекта и принимаем решение по приоритету.
3. Маршрутизация
Маршрутизация в РИБ остается такой же, при регистрации изменений определяется список получателей. В дальнейшем можно сделать маршрутизацию в БДО, но для текущих нужд все устраивает.
4. Отказоустойчивость
Важно добиться аналогичного уровня надежности доставки объектов, как у РИБ. Все объекты пишем в транзакции, при неудаче откатываемся и считаем количество попыток.
Сеем
Инициатором всех процессов является БДО. В ней для каждой ПБ есть регламентное задание для обмена, выполняющее 2 процедуры: ПрочитатьИзменения(..) и ЗаписатьИзменения(..).
Чтение данных (концептуальный вариант)
Запись изменений в базу-получатель
- В обменной базе сразу после получения данных формируется выборка XML-текстов, которые нужно передать в базу-получатель (эта же база только что была базой-отправителем).
- Запись одного XML-текста регистра сведений “ОчередьПакетов” блокируется в обменной базе.
- XML-текст передаётся по web-сервису в базу-получатель, десериализуется в объект 1С.
- Объект 1С записывается в базе-получателе в транзакции. В случае документа, также происходит запись проводок.
- Запись из регистра сведений “ОчередьПакетов” удаляется.
- Снимается блокировка с записи XML-текста регистра сведений “ОчередьПакетов” в обменной базе.
- Операции 2-8 выполняются по циклу до тех пор, пока не закончится выборка.
Концептуальная схема обмена
Приведенная ниже схема не содержит в себе процессов по контролю транзакционной целостности, механизмов возобновления работы после сбоя и смены подразделений у документов. Целью схемы является демонстрация концепта потоков данных. Полный контур процессов выглядит достаточно громоздко, поэтому здесь не приведен. На схеме продемонстрирован процесс относительно обмена с одной базой, из которой сначала читаем данные, а потом отправляем.
Пожинаем
- Ускорение обменов
- Обменная база значительно повышает скорость передачи данных между ЦБ и подчиненными базами.
- Разгружает центральную базу. Обменной базе достаточно обменяться с обменной базой только один раз, которая далее обменивается с периферийными базами.
- Значительно реже случаются конфликты блокировок. Сервер обмена не блокирует центральную базу целиком при выполнении обмена. Блокировка данных (начало транзакции - конец транзакции) включается только на момент передачи одного экземпляра объекта. Это существенно разгружает базу данных, если управляемые блокировки таблиц в конфигурации ещё не включены.
- Отказоустойчивость
- Восстановление передачи данных с точки прерывания. При повторном запуске передача продолжится с того же места. Можно самостоятельно остановить выполнение передачи данных.
- Мониторинг и статистика обменов
- Видим очередь объектов в режиме он-лайн, можем анализировать и конфигурировать объемы данных и расписание.
- Сбор статистики: понимаем, что “ходит” в обмене, делаем выводы для оптимизации.
- Информирование пользователя о статусе обмена объекта.
- Обменная база в инфраструктуре позволяет использовать полезные сервисные функции:
- Исполнение произвольного кода на периферии.
- Хранение тяжелых регистров сведений (нетиповое версионирование, например).
- Централизованное выполнение регламентов (последовательности и т.д).
Не баги, а фичи….
В подходе, при котором обмен идет без загрузки изменений, есть возможность нарваться на логическую проблему. В случае, если ожидаемое поведение модифицированной конфигурации зависит от данных, и на эти данные в не модифицированной конфигурации настроена иная логика, то изменение данных без изменения конфигурации приведет к логической ошибке. Однако, при соблюдении некоторых техник в разработке (использование версий, например) данный тип проблем можно избежать. Эта категория вопросов будет всегда при разделяемом обмене (отдельно данные, отдельно конфигурации).
Время собирать камни помидоры обратную связь
К тому моменту, когда система стала работать слаженно и бесперебойно, мы прошли через огромное количество споров по поводу технологии обмена. На Инфостарте есть куча отличных примеров от вдохновляющих нас ребят по работе с RabbitMQ и прочих интеграционных шин. На выбор технологии на платформе 1С повлияли экзистенциально-языческие сомнения в стабильность связки 1С и решений из “внешнего мира”. Хотелось обойтись без привлечения сторонних средств с целью избежания bus-фактора в команде. Обращения в техподдержку после ввода системы снизились в разы. Поддержка решения не требует специфических знаний сторонних технологий.
В итоге мы получили достаточно стабильное решение вопросов обмена при наличии устойчивой связи. Наличие установленного на филиалах apache-сервера не являлось для нас проблемой, т.к они уже были подняты для других задач. Мы надеемся, что данный подход возможно поможет оптимизировать обмена на других предприятиях. В любом случае любая обратная связь по вышеописанной концепции будет нам ценна и полезна.
Механизм РИБ — механизм распределенных информационных баз - это когда у вас есть главная база и подчиненная(ые). Главная база может быть только одна, подчиненных может быть много. Каждая подчиненная база может иметь свои подчиненные базы, для которых она будет главной.
Вот посмотрим на картинку из первой ссылки по запросу в Яндексе:
РИБ используется для обмена данными. Причем не только теми данными, с которыми работает пользователь, но и данными изменения конфигурации. То есть РИБ позволяет передавать изменения конфигурации. Но изменить конфигурацию можно только в главной базе!
Визуализируем:
У нас большая компания и много филиалов. Есть доработанная УНФ, которую мы гордо называем УБФ(Управление Большой Фирмой). Но мы решили, что хватит терпеть то, что все филиалы имеют доступ к документам всех филиалов и каждому филиалу решили сделать отдельную базу, которую синхронизировать с нашей основной базой для передачи данных. Что ж, можно. Сделали.
И внезапно мы решили изменить картинку, которая появляется при входе в базу, захотели поместить туда логотип нашей фирмы, а почему бы и нет?
Как запилить картинку во все базы всех филиалов? Ну при текущем варианте, что у всех филиалов отдельная база, только руками. Руками специалистов, которые умеют заходить в конфигуратор и знают что нужно там нажать.
А вот если бы мы сделали подчиненные базы для филиалов, то есть использовали РИБ, то и данными бы обменивались, как при обычной синхронизации, и картинка бы сама добавилась во все "базы-дочки". Однако, в конфигуратор зайти бы все-таки пришлось, но только чтобы нажать кнопочку "Обновить конфигурацию базы данных", вот картинка:
Как создать подчиненную базу, на пальцах:
я буду использовать Управление торговлей, редакция 11 (11.4.13.275), но способ, в целом, одинаковый во всех типовых конфигурациях.
1) Сначала проделаем шаги, как при настройке обычной синхронизации:
2) . поставим галочку, нажмем.
4) тут ознакомимся с описанием. Я выберу обычную настройку, но если бы мы следовали примеру выше, то нужно было бы выбрать "с фильтром" и там одним кликом выбрать нужный филиал.
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
Задача: требуется настроить обмен данными через файл из 1С: Управление торговлей 11 (далее УТ) в 1С: Бухгалтерия 3.0 (далее Бухгалтерия).
- платформа 1С: Предприятие 8.3 (8.3.13.1690),
- конфигурация Управление торговлей, редакция 11 (11.4.7.150),
- конфигурация Бухгалтерия предприятия (базовая), редакция 3.0 (3.0.72.72)
- режим Файловый (без сжатия).
- настроить параметры подключения,
- настроить правила отправки и получения данных,
- выполнить начальную выгрузку данных.
- настроить правила отправки и получения данных,
- выполнить сопоставление и загрузку данных,
- выполнить начальную выгрузку данных.
ШАГ 1. Настройка в УТ
Переходим в раздел «НСИ и администрирование» и выбираем пункт «Синхронизация данных». Обязательно должен быть указан префикс информационной базы. В нашем случае это «ЦБ».
Устанавливаем флаг «Синхронизация данных» и переходим по ссылке «Настройки синхронизации данных». Нажимаем кнопку «Новая синхронизация данных». В открывшемся окне выбираем конфигурацию, с которой будем настраивать обмен. В нашем случае это «Бухгалтерия предприятия, редакция 3.0».
Откроется окно настройки синхронизации. Выберем пункт «Настроить параметры подключения».
Так как обмен будет настраивать через файл, то выбираем пункт «синхронизация данных через файл, без подключения к другой программе».
Далее укажем каталог и настроим архивацию файлов.
Далее укажем префикс базы бухгалтерии и название файла с настройками синхронизации.
Обратите внимание: если указать префикс, по которому уже есть обмен, то будет ошибка, программа предложит указать уникальный код. Нажимаем «Далее» и на этом заканчивается первый шаг настройки.
В результате у нас появится два файла в указанной папке: файл с данными (Message_ЦБ_БП.zip) и файл с настройками обмена (Синхронизация данных через универсальный формат.xml). Обратите внимание: если в УТ попробовать перейти к этапу «Настроить правила отправки и получения данных», то будет ошибка.
ШАГ 2. Настройка в Бухгалтерии
Перед настройкой синхронизации в Бухгалтерии нам понадобятся два файла, созданных на предыдущем шаге. Разместим файлы Message_ЦБ_БП.zip и Синхронизация данных через универсальный формат.xml в любую папку на компьютере с базой Бухгалтерии. Внимание: если Бухгалтерия находится на одном компьютере с УТ, то ничего переносить не нужно. Будем использовать ту же папку, что и для УТ.
Сначала перейдем в раздел «Администрирование» и выберем пункт «Синхронизация данных». В открывшемся окне проверим, чтобы префикс указанной базы совпадал с префиксом, который мы указали на первом шаге.
Устанавливаем флаг «Синхронизация данных» и переходим по ссылке «Настройки синхронизации данных». Нажимаем кнопку «Новая синхронизация данных». В открывшемся окне выбираем конфигурацию, с которой будет настроен обмен. В нашем случае это «1С: Управление торговлей, редакция 11».
Откроется окно настройки синхронизации. Выберем пункт «Настроить параметры подключения».
Так как обмен настраиваем через файл, то выбираем пункт «синхронизация данных через файл, без подключения к другой программе». На Шаге 1 мы уже создали файл с настройками обмена Синхронизация данных через универсальный формат.xml, поэтому выберем его. Если был создан другой каталог и туда скопировали файл с настройками обмена, то выбираем его.
Далее укажем каталог и настроим архивацию файлов. В данном случае каталог может быть тот же самый или тот, в который перенесли два файла.
Далее проверяем настройки префиксов и на этом настройка параметров подключения в Бухгалтерии завершена.
Далее переходим к следующему этапу «Настройка правил отправки и получения данных».
Так как задачи выгрузки из Бухгалтерии у нас нет, то в настройках отправки данных укажем «не отправлять».
В настройках получения данных укажем типовые настройки. При необходимости можно указать свои настройки.
Нажимаем «Записать и закрыть». Далее переходим к следующему этапу «Выполнить начальную выгрузку данных».
После выполнения операции будет создан в каталоге обмена файл с данными Message_БП_ЦБ.zip. На этом этап настройка обмена в Бухгалтерии закончена.
ШАГ 3. Окончание настройки в УТ
Вернемся в УТ. Если использовался другой каталог, то в папку обмена УТ перенесем файл, созданный на прошлом шаге Message_БП_ЦБ.zip.
Продолжим настройку синхронизации в УТ с этапа «Настроить правила отправки и получения данных».
В настройках обратим внимание на два поля.
1.Отправлять только используемую в документах нормативно-справочную информацию.
2.Отправлять все, начиная с даты. Это поле полезно, так как бывает, что нужно начать синхронизацию с определенного времени. Например, учет в УТ уже был настроен ранее, а в
Бухгалтерии только начинаем вести учет. Тогда нет необходимости переносить все документы из УТ в Бухгалтерию. Или второй случай: нужно поменять настройки обмена, но чтобы они действовали только для документов с определенной даты.
Все остальные поля заполняем в зависимости от учета.
В нашем случае настройка получения данных не требуется. Оставляем ее без изменений.
Нажимаем «Записать и закрыть». Переходим к следующему этапу «Выполнить сопоставление и загрузку данных».
В нашем случае программа ничего загружать не будет и перейдет к следующему этапу.
На последнем этапе «Выполнить начальную выгрузку данных» программа выгрузит данные из УТ в файл Message_ЦБ_БП.zip.
Обратите внимание (для случая с двумя каталогами): полученный файл Message_ЦБ_БП.zip копируем в каталог обмена Бухгалтерии. В Бухгалтерии выполняем синхронизацию. При этом Бухгалтерия сначала загрузит данные из присланного файла Message_ЦБ_БП.zip, потом обновит свой файл выгрузки Message_БП_ЦБ.zip Этот файл выгрузки Message_БП_ЦБ.zip нужно скопировать обратно в каталог обмена УТ и в УТ выполнить синхронизацию. При этом УТ сначала загрузит данные (если они там есть) из файла Message _БП_ЦБ.zip, а потом обновит свой файл выгрузки Message _ЦБ_БП.zip и т.д.
ШАГ 4. Итоги
В результате мы получили файл с настройками обмена Синхронизация данных через универсальный формат.xml и два файла с данными: Message_БП_ЦБ.zip (данные из Бухгалтерии) и Message_ЦБ_БП.zip (данные из УТ).
Читайте также: