1с не найден узел обмена для загрузки данных
На нашем сайте профессионалы делятся своим опытом и разработками. Вы получаете доступ к уникальному и самому полному хранилищу материалов для 1С, состоящему из более 30 000 отчетов, обработок, видео и т.д.
Рейтинг: 504
Работая с 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
Удаление расширений через командную строку
Для удаления всех расширений (файловый вариант):
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /f "Полный_путь_к_базе" /N "Имя_пользователя" /P "Пароль_пользователя" /DeleteCfg -AllExtensions
Для удаления одного расширения по имени (файловый вариант):
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /f "Полный_путь_к_базе" /N "Имя_пользователя" /P "Пароль_пользователя" /DeleteCfg -Extension "ИмяРасширения"
Для удаления одного расширения по имени (серверный вариант, SQL):
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S «ИмяСервера/ИмяИнформБазы» /N "Имя_пользователя" /P "Пароль_пользователя" /DeleteCfg -Extension "ИмяРасширения"
- После отключения узла заходим в конфигуратор и удаляем расширения, которых нет в центральной базе, и сохраняем базу;
- При первом входе в базу в режиме предприятия 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С спросит восстановить узел ВАЖНО его ВОССТАНОВИТЬ. Либо восстановить главный узел можно с помощью обработки;
- После чего синхронизация проходит в штатном режиме.
После выполнения этих действий работоспособность распределенной информационной базы будет восстановлена.
Внимание! Важный момент на "19" платформе (8.3.19.1150, 8.3.19.1467) очень много проблем с расширениями их обновлениям и доработкой. В один прекрасный день после очередного изменения или доработки расширение, 1с начнет падать в дамп (ошибку), не давай обновить расширение. Лечится либо откатом на "18" платформу либо на "20", если такой возможности нет, выгружаете базу разворачивайте на другой платформе обновляете или исправляете расширение и грузите базу назад. 1С и само расширение работает нормально и после проделанной работы. Способ рабочий.
Надеюсь, описанный опыт кому-то поможет и сэкономит кучу времени по решению проблем, возникших в распределенных базах.
С начала года для бухгалтера была развернута новая база Бухгалтерии редакции 3.0. На данный момент требуется обмен данными УТ 10.3 с БП в одностороннем режиме (данные приходят из УТ в БП).
Вчера целый день бился так и не понял что я делаю не так данные не загружаются (из УТ в БП 2.0 всегда все работает без проблем лишь бы узлы совпадали а тут. а вот выгрузка осуществляться хотя я вроде как установил что односторонний режим только принятие данных.
Делал следующие действия (Вариант 1):
В УТ
1. В параметрах учета уже стояла галочка использовать обмен данными, и префикт "УТ"
2. Далее "Сервис - Обмен данными с продуктами на платформе 1С: Предприятие 8.2 - Обмены данными" - создаю синхронизацию данными
3. Создаю новую синхронизацию - "Другие каналы связи (сетевой катало. )"
4. Настройки параметров синхронизации данных - указал наименование и префик базы БП
5. Изменил правила выгрузки, выгружать данные с 01.04, и указал выгружать всю информацию (везде поставил галочки, выгрузка по всем организациям в базе)
6. Сохранил "Настройки для второй базы", произвел выгрузку (имя файла выгрузки Message_УТ_БП)
В БП
1. Администрирование - Настройки синхронизации данных, указал префикс "БП" и поставил галочку "Синхронизация данных" - "Настроить синхронизацию данных" и выбрать вид синхронизации УТ 10.3
2. Загрузил "Настройки для второй базы" - указал путь к каталогу (папке с фалом обмена)
3. Далее все без изменений, и данный не загружаются (: Тип не определен (РегистрСведенийЗапись.АдресныеСокращения)
СоответствиеТиповДанныхДляЗагрузки().Вставить(Тип(ИмяТипа), СоответствиеТипа)
PS При выгрузке фала обратил внимание что имена узлов не совпадают, у меня после выгрузки из УТ имя файла "Message_УТ_БП" а после выгрузки из БП "Message_002_УТ"
Не проблема решил использовать другой вариант выгрузки из УТ, заменить имя узла БП (как менять код узла в БП 3.0 так и не понял) (Вариант 2)
В УТ
1. Иду "Операции" - "План обмена" - меня код БП на 002
2. Произвожу выгрузку, имя фала "Message_УТ_002"
Обновила на последнюю версию, этой ошибки теперь нет, но теперь еще страннее! Сделала копию новую и торговли и бухгалтерии, 2.0 заново превратила в 3.0, сохранила эти копии, попробовала выгрузить, получила ошибку в 11-48, подгрузила сохраненнные копии, выгружаю сейчас - впервые в этой копии - и вижу опять ошибку в 11-48! Как такое может быть? Выгрузку можно запускать с любой стороны? И из торговли и из бухгалтерии? В БП 3.0 это называется "синхронизация"?
В зависимости от настроек, если через файл то ,внезапно, придется в обоих базах запускать обмен. А по теме, стоит до предела обновить обе базы.
Обновила! Перегрузка - через прямое подключение. Сейчас в БП мне говорит - данные получены только что (но ничего не загрузилось), а в торговле - ошибка - нет транзакции.
А до обновления правила работали? Обмен заново настраивала или обмен обновлен обработкой? Базы типовые?
У меня всё работало 10.3 -> 2.0, теперь переходим на 3.0. Как только отлажу перегрузку - так сразу. Базы почти типовые, в том смысле, что ничего нетипового перегружать не надо. Однажды с 50-й попытки у меня до обновления что-то кривенько перегрузилось! Правила брала и из 10.3 (из обновления) и из конфигурации 3.0.
Я бы вот картинку провесила. Почему БП мне радостно говорит, что синхронизация закончена, при этом выгрузка произведена, а загрузка и не производилась? При том, что сама мне сообщила, что обмен односторонний, УТ -> БП
А настроить выгрузку только со стороны БП можно? В том смысле, что создать настройку в БП с подключением к УТ, а в УТ ничего по этому поводу не писать вовсе? Или там тоже нужно делать настройку? А еще, помню, раньше была возможность определить, как ищутся контрагенты - по инн или по коду, как номенклатура. А сейчас я что-то не нашла ничего такого.
Если в качестве способа обмена был выбран обмен через прямое подключение к информационной базе корреспондента, то на следующем шаге необходимо выполнить аналогичные действия для конфигурации Бухгалтерия предприятия (см. Применение фильтров выгрузки). Т.е. настраивать-таки надо с 2 сторон.
Ошибка при загрузке данных: : Не найден узел обмена для загрузки данных. План обмена: ОбменУправлениеТорговлей103БухгалтерияПредприятия30, Код: 002Обработка.КонвертацияОбъектовИнформационныхБаз.МодульОбъекта(14100)>
Чтобы загрузить данные из торговли в бухгалтерию - синхронизацию надо запускать из торговли? Или всё равно? Ведь и там и там описано и что туда надо и что обратно?
ВНЕШНЕЕ СОЕДИНЕНИЕ: Ошибка при загрузке данных: : Не найден узел обмена для загрузки данных. План обмена: ОбменУправлениеТорговлей103БухгалтерияПредприятия30, Код: 002Обработка.КонвертацияОбъектовИнформационныхБаз.МодульОбъекта(14100)>
Я запускаю синхронизацию с кодом 001, а она мне говорит, что не могу - с кодом 002 не найдена. С какой стати??
Создала новый план обмена 003 и там и там, выгрузку запускаю прямо из планов обмена, при выгрузке из торговли говорит - нет плана обмена с кодом 002! (хотя и с 002 тоже есть!)
Поражает меня, что после загрузки базы из архива (в пятницу делала!) Мне журнал регистрации показывает ошибки синхронизации за утро. Это правильно? Чтоб всё заново начать. нужно на новое место загрузить?
При задании выгрузки из УТ 10.3 в БП 3.0 можно задать список выгружаемых документов? В помощнике настройки обмена я этого не нашла!
Код узла и код плана обмена - это разные вещи, это факт. Вам какой список выгружаемых документов нужен? Сижу и думаю, сколько взять с коллеги по мисте за настройку обмена? 11.050 рублей или со скидкой 11.000.
В шаблоне конфигурации есть обработка Конвертация обменов с БП 2.0.epf. За 510 рублей покажу, где она находится. Если попросите, то скидка 10 рублей, как для коллеги. За восемь дней у вас ничего не вышло, а вы "Ого! Ничего себе! "
Так база по сути - та же? К тому же, если в регистрации ничего нет - так ничего и не перегрузится, разве нет? Всё наоборот?
Всё обновили, поправили, привели к абсолютно типовому варианту - : Ошибка при вызове метода контекста (ВыполнитьВыгрузкуДанных) ОбработкаОбменаДаннымиВнешнееСоединение.ВыполнитьВыгрузкуДанных(ОбработкаДляЗагрузкиДанных); по причине: Произошла исключительная ситуация (1C:Enterprise 8.3.5.1248): : Поле объекта не обнаружено В чем может быть причина?ОбщийМодуль.ОбменДаннымиСервер.Модуль(2826)>
Конфигурация узла распределенной ИБ не соответствует ожидаемой. Одна из самых популярных ошибок РИБ. Приведены стандартная методика устранения (уже публиковалась ранее) и расширенная (для сложных случаев).
Для начала привожу список используемых мной сокращений:
- РИБ — распределенная информационная база
- ЦБ — центральная база, корневой узел РИБ
- УБ — удаленная база, БД удаленного узла РИБ
По собственному опыт могу сказать, что сталкивался с двумя причинам возникновения ошибки:
Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.
Для исправления использую 2 методики, в зависимости от ситуации.
ПЕРВАЯ МЕТОДИКА
- выгружаем из ЦБ cf-файл;
- отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
- заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню «Загрузить конфигурацию из файла» (а не сравнением-объединением. );
- восстанавливем признак РИБ для УБ.
В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда…
ВТОРАЯ МЕТОДИКА
Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.
Предыстория: у клиента настраивали каскадную РИБ и ошибка возникла в первом уровне каскада (второй уровень всё это время работал безупречно). Разработка конфигурации велась совместно с IT-службой клиента и с момента возникновения ошибки конфигурация ЦБ успела несколько раз поменяться. Вариант с откатом изменений не рассматривался даже в принципе, т.к. потеря части данных и остановка работы нескольких подразделений были совершенно неприемлимы. Первый вариант исправления ошибки каких-либо ощутимых результатов не дал. В связи со чем пришлось искать другие пути решения.
Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги «Профессиональная разработка в системе 1С:Предприятие 8» дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.
Тестовые эксперименты прошли удачно. На рабочих базах тоже всё прошло благополучно.
Итак, последовательность действий:
- выполняем действия 1 — 4 первой методики;
- выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
- выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
- в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
- производим загрузку файла из 4-го пункта в УБ;
- обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из ЦБ
нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен «00000000000000000000000000000000». )
Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!
Задача: требуется настроить обмен данными через файл из 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 (данные из УТ).
Читайте также: