Настройка синхронизации; обмена данными; между базами 1С 8

Настройка синхронизации (обмена данными) между базами 1С 8.3 на примере конфигураций УТ 11 и БП 3.0

Приветствуем всех читателей портала makrus.ru! В этой статье мы настроим с Вами типовой обмен данными (он же синхронизация) с двумя типовыми базами на платформе 1С 8.3 . Если Ваши базы не являются типовыми, или одна из них доработана, то возможно стандартный обмен данными не будет корректно работать. Более подробная информация о настройке обмена данными между НЕТИПОВЫМИ базами УТ и БП, а также что такое обмен и зачем он нужен в принципе.

Давайте рассмотрим простой пример из реальной жизни. Допустим у нас есть фирма которая занимается оптово-розничной торговлей, также в этой фирме как и в любой другой ведется бухгалтерия. На предприятии установлены две типовые базы, это УТ (управление торговлей) и БП (бухгалтерия предприятия), соответственно в каждой из баз ведется свой учет, в УТ управленческий для отражения всех операций связанных с торговлей, в БП бухгалтерский. Чтобы не делать двойную работу, т.е. не создавать одни и теже документы в двух базах (ведь движения должны быть по управленческому и по бухгалтерскому учету) мы как раз и настроим синхронизацию между этими базами.

Обмен данными будем настраивать односторонний, из УТ —> БП. Также возможно настроить двухсторонний обмен, но на практике это не так часто требуется, поэтому в нашем примере мы его рассматривать не будем.

Пошаговая инструкция по настройке синхронизации 1С:Бухгалтерия предприятия 3.0 и 1С:Зарплата и управление персоналом 3.1

В данной статье подробно описан процесс настройки синхронизации 1С:БП и 1С:ЗУП, а также описаны возможные варианты настройки синхронизации.

Перечень синхронизируемых данных

Документы:

Регламентированные отчеты:

Расчет по страховым взносам;

Подтверждение вида деятельности;

Соответствие условий труда;

Сведения о среднесписочной численности;

Необходимые условия для синхронизации

Для успешной настройки синхронизации данных БП 3.0 и ЗУП 3.1 обязательно выполнение ряда условий:

1. Релизы конфигурации ЗУП и БП должны быть выпущены примерно в одно время.

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

2. Настройку синхронизации должен настраивать пользователь с полными правами.

Если в вашей информационной базе заведены пользователи, то настраивать синхронизацию должен пользователь с полными правами.

3. Данные справочников «Подразделения» и «Отражения зарплаты в бухучете» должны быть заполнены идентично.

Подразделения организаций, по которым будет настроена синхронизация должны быть одинаковыми. Если в БП у организации 3 подразделения, в которых трудоустроены сотрудники, то и в ЗУП у этой же организации должно быть 3 подразделения с трудоустроенными сотрудниками. Наименования подразделений может быть различным, например, «Администрация» и «Административный отдел».

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

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

– справочник «Отражения зарплаты в бухучете» в БП.

Перейти к справочнику можно следующим образом:

При создании нового способа отражения необходимо заполнить поля «Наименование» и «Счет», а также аналитику, которая появиться после выбора нужного счета. Если в ИБ (информационной базе) есть организации, применяющие УСН, также необходимо заполнить реквизит «Отражение в УСН».

– справочник «Отражения зарплаты в бухучете» в ЗУП

Перейти к справочнику можно следующим образом:

В ЗУП справочник хранит только наименование способа отражения, так как проводок в конфигурации нет.

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

Настройка синхронизации

Для начала нужно установить флаг «Синхронизация данных» и ввести префикс ИБ.

Для этого необходимо перейти в раздел Администрирование – Синхронизация данных как в БП, так и в ЗУП.

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

Далее можно начать настройку в любой из ИБ. В примере настройка синхронизации будет начинаться в ЗУП.

Перейдем по ссылке «Настройки синхронизации данных».

Далее открывается список всех существующих синхронизаций, если синхронизация настраивается впервые, список будет пуст.

Нажимаем кнопку «Новая синхронизация данных».

Открывается список программ, с которыми можно настроить синхронизацию данных, так как мы начали настройку в ЗУП, то выбираем «Бухгалтерия предприятия ред. 3».

Далее на форме отразится последовательный список действий. По ссылке «Настроить параметры подключения» переходим к первому этапу настройки.

Первый этап настройки в ЗУП. Настройка параметров подключения.

В окне представлены возможные варианты настройки подключения. Необходимо выбрать подходящий вам способ подключения к БП. Варианты настройки перечислены на картинке ниже.

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

Чтобы выбрать вариант, подходящий вам, необходимо ответить на вопрос: «Как располагаются базы данных?». Есть 3 основных варианта расположения ИБ: на локальном компьютере, на сервере, в облаке.

Эту информацию можно узнать, нажав кнопку «О программе».

Вариант расположения базы можно узнать из значения в строке «Режим»

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

Общие принципы

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

Ну тут сразу возникает как минимум две идеи:

• Использовать планы обмена;
• Использовать самописный вариант синхронизации;

Но я сразу добавлю еще и третий вариант – гибридный:

• Использовать самописный вариант синхронизации, но данные регистрировать при помощи планов обмена.

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

Планы обмена

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

Какие у нас есть плюсы в использовании РБД?

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

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

Какие минусы, при переносе этого всего в область мобильной платформы:

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

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

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

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

Первые два пункта, которые являются самыми главными – абсолютно бесполезны в мобильной среде. Что, по большей части, сводит на нет все плюсы. Хотя, я не исключаю, что 1С-таки что-то придумает.

Но кроме РБД у нас еще есть и полные обмены, но у них тоже присутствуют эти критерии.

Универсальный обмен данными на основе КД

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

А именно – в мобильной платформе нет запросов. Это сводит на нет использование данного метода, ну если только кто-то не решит переписать эти обработки так, чтобы они работали без запросов.

Планы обмена + КД + Промежуточная база

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

В итоге у нас выйдет следующая схема:

Давайте теперь посмотрим, что же происходит тут. Зелеными стрелочками я показал обмен данными, а красной – обмен конфигурацией. Т.е. логика проста – МП получает данные от ПБ, и от нее же получает конфигурацию. А ПБ обменивается данными с ЦБ.

В чем преимущество данной архитектуры:

У вас одна и та же база для мобильного приложения и для стационарного;

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

Нет необходимости конфигурировать ЦБ для реализации обменов, так как при обмене между ЦБ и ПБ – вы можете использовать типовой обмен данными при помощи «Конвертации данных»;

Так как у вас метаданные в МП и ПБ будут идентичными, то для обмена между МП и ПБ – вы можете использовать план обмена;

• Использование ПБ – это еще одно звено, а чем меньше звеньев, тем стабильней;

Архитектура ЦБ(8.х) ↔ МП (самописный обмен)

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

Что особенного происходит в данном случае? У нас есть центральная база, в которой настроены планы обмена (соответственно мы «гоняем» данные из приложения в ЦБ и обратно), но одновременно у нас есть отдельная база, в которой мы пишем конфигурацию для мобильных телефонов.

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

Минусы такого подхода очевидны – необходимо постоянно переделывать конфигурацию, нужно создавать новые планы обменов и/или web-сервисы и т.д.

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

Почему ЦБ должна иметь доступ в интернет, почему ЦБ на платформе 8.х? Все очень просто, самый удобный способ обмена – это обмен при помощи веб-сервисов. А они появились с 8.х и требуют выход базы в интернет.

Гибрид

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

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

Таким образом, вы получаете ряд преимуществ:

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

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

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

Так как у вас практически все будет гоняться между ЦБ и ПБ при помощи КД, и только заказы будут самописные, то, когда, наконец то, в мобильной платформе появятся запросы – вы очень быстро сможете вообще избавиться от ПБ и все перенести полностью на мобильный телефон, при минимальном редактировании ЦБ.

Какой вариант синхронизации выбрать?

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

К примеру, если вы выберете вариант самописного обмена, то вы должны понимать, что на любой чих клиента – вам придётся обновлять ЦБ, а если база работает 24/7? То я так думаю, что клиент вряд ли будет рад вашим обновлениям среди рабочего дня. Тогда вам подойдет второй или третий вариант.

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

PDF-версия статьи для участников группы ВКонтакте

Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.

Статья в PDF-формате

Вы можете скачать эту статью в формате PDF по следующей ссылке:
Ссылка доступна для зарегистрированных пользователей)

Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)

Какие данные переносятся при синхронизации

Документ «Отражение зарплаты в бухучете» попадает в одноименный документ в «1С:Бухгалтерии 8» и уже там, на основании перенесенных документов, происходит формирование проводок.

Документы ведомостей переносятся в «1С:Бухгалтерию 8» в один документ «Ведомость на выплату зарплаты».

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

Если вы в программе «1С:Бухгалтерия 8» обнаружили ошибку в синхронизируемых файлах, то рекомендуется исправлять данные в базе «1С:Зарплата и управление персоналом 8», тогда данные в «1С:Бухгалтерии 8» изменятся автоматически. Если соблюдать данное правило, то при синхронизации в приоритете будут данные из «1С:Зарплаты и управлении персоналом 8» и не будет путаницы в данных. Также приоритет данных можно настроить самостоятельно, или программа выдаст сообщение при конфликтных ситуациях.

При синхронизации все настройки базы «1С:Бухгалтерия 8» основаны на «Параметрах учета» базы «1С:Зарплаты и управлении персоналом 8».

Также при переносе данных стоит учитывать еще один фактор. В базу «1С:Бухгалтерии 8» при синхронизации переносятся только физические лица. Не стоит в «1С:Бухгалтерии 8» на основании этих физлиц создавать сотрудников, так как во всех бухгалтерских документах, где должны быть указаны сотрудники, буду подставляться данные из справочника «Физические лица».

И напоследок укажем еще один подводный камень, связанный с переносом. Представьте ситуацию: вы в базе «1С:Зарплата и управление персоналом 8» создали документ «Ведомость …» и при синхронизации выгрузили ее в «1С:Бухгалтерию 8». По каким- то причинам данный документ был удален в базе «1С:Бухгалтерии 8». В этом случае при повторной синхронизации данный документ не будет добавлен снова, так как при синхронизации в регистре соответствий программа видит, что данный документ уже перенесен. В такой ситуации есть только одно решение: физически удалить в «1С:Зарплате и управлении персоналом 8» данную ведомость и создать новую, а потом запустить синхронизацию. Так как нового документа нет в регистре соответствий, он с легкостью перенесется в информационную базу бухгалтерии.

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

Возможности интеграции ЕС НСИ и систем – потребителей НСИ

Первичная загрузка контента

Первичная загрузка – это стартовая процедура при начале эксплуатации (подготовке к эксплуатации) ЕС НСИ.

Возможны несколько сценариев первичной загрузки:

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

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

При настройке миграции данных учитывается несколько параметров:

• Таблица мэппинга справочников. Таблица определяет – какой справочник ЕС НСИ является источником информации для каких справочников, в каких информационных системах. При этом учитывается, что несколько справочников ЕС НСИ могут быть источниками для одного справочника конкретной ИС. И, наоборот, один справочник ЕС НСИ – источник для нескольких справочников ИС. Поэтому, для таких справочников указываются условия разделения информации.
• Таблица переходных ключей. Посредством этой таблицы настраивается мэппинг конкретных записей ЕС НСИ в системы- потребители НСИ.
• Таблица подстановки значений. Данная таблица регулирует замену ссылочных значений атрибутов справочников ЕС НСИ на значения атрибутов связанных объектов. Данная замена (подстановка значений) необходима, если в системах- потребителях не ведутся соответствующие связанные объекты (подчиненные и вспомогательные справочники).

Функции подсистемы интеграции

Помимо объединения, централизации объектов НСИ, упорядочивания процессов ведения и использования НСИ, конфигурация обеспечивает интеграцию с системами-потребителями на уровне объектов НСИ (мастер-данных). Реализация интеграционных функций конфигурации подразумевает настройку механизмов обмена данными с типовыми и нетиповыми конфигурациями для платформы «1С: Предприятие 8». Помимо прикладных решений компании 1С, конфигурация позволяет настроить и использовать обмен данными с различными автоматизированными системами. Это позволяет осуществлять интеграцию данных в мультиплатформенных информационных средах. Контроль доставки данных в системы- потребители осуществляется посредством возврата квитанций о доставке.

Подсистема интеграции обеспечивает выполнение следующих функций:

• Создание сценариев синхронизации для любого справочника и каждой целевой ИС.
• Синхронизация данных в соответствии с разработанными сценариями.
• Ведение протокола синхронизации.
• Автоматический/ ручной запуск репликации после появления изменений в контенте.
• Запуск репликации по расписанию.
• Конфигурация предоставляет необходимые сервисные функции, которые позволяют осуществлять загрузку и выгрузку данных с использованием файлов – источников формата XML

Администрирование ЕС НСИ

Подсистема администрирования предназначена для определения списка пользователей ЕС НСИ, назначения прав доступа к информации, установки/снятия различных ограничений на работу с объектами НСИ, реализации процессов обеспечения протоколирования работы системы.

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

• Создание новой учетной записи пользователя.
• Редактирование учетных записей пользователей.
• Назначение ролевых функций пользователям:
• Пользователь системы управления НСИ;
• Эксперт службы НСИ
• Старший эксперт службы НСИ;
• Методолог службы НСИ;
• Установка/снятие ограничений прав доступа на модификацию для любого поля каждого из справочников;
• Ведение журнала регистрации работы пользователей.