Секция (квитанция) содержит служебную информацию (для простоты предположим, что сообщение идет из приложения «1С» в стороннее приложение):

Если сообщение идет в обратном направлении – от стороннего приложения в приложение «1С», стороннее приложение должно соответствующим образом заполнить секцию .

Приложения «1С» ведут учет отправленных и полученных сообщений синхронизации и ожидают того же от сторонних приложений. Для чего это делается – изложено ниже.

Механизм квитирования

Приложения «1С» в ходе синхронизации передают только информацию об изменениях, произошедших с бизнес-сущностями со времени последней синхронизации (чтобы минимизировать объем передаваемой информации). При первой синхронизации приложение «1С» выгрузит все бизнес-сущности в формате EnterpriseData в XML-файл (поскольку все они являются «новыми» для внешнего приложения). Следующий шаг за сторонним приложением –оно должно обработать информацию из XML-файла и при следующем сеансе синхронизации поместить в секцию информацию, что сообщение от «1С» за определенным номером успешно принято (поместить в поле ReceivedNo номер полученного от «1С» сообщения). Сообщение-квитанция является для приложения «1С» сигналом, что все бизнес-сущности успешно обработаны внешним приложением и информацию о них передавать больше не нужно. Помимо квитанции XML-файл от стороннего приложения также может содержать данные для синхронизации (в секции ).

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

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

Приложение «1С» после обработки файла сформирует XML-файл, который будет содержать сообщение-квитанцию и новые данные для синхронизации со стороны «1С» (если такие есть со времени последнего сеанса синхронизации).

Обмен через веб-сервис

При использовании веб-сервиса инициатором сеанса обмена выступает стороннее приложение. Для получения данных от приложения «1С» ему нужно вызвать веб-метод GetData, передав в качестве параметров метода уникальный код приложения, введенный на . В ответ «1С» вернет файл, содержащий данные о бизнес-сущностях в формате EnterpriseData. Формат файла описан.

Чтобы передать данные в «1С», приложение должно вызвать веб-метод PutData, передав как параметры уникальный код приложения и заархивированный файл в описанном выше формате.

Обмен через другие каналы

В случае обмена данными через каталог/FTP каталог или электронную почту инициатором обмена будет выступать приложение «1С». Оно будет помещать в соответствующий канал (каталог или почтовый ящик) файл описанного выше формата и ожидать от стороннего приложения в этом же канале ответных файлов. В случае обмена каталог/FTP каталог имя файла должно быть составлено специальным образом, чтобы приложение «1С» смогло его обработать. В случае обмена по электронной почте тема письма должна быть составлена по определенному правилу, а заархивированный файл с данными должен быть приложен к письму.

Заключение

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

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

Причин популярности синхронизации несколько:

• Не надо отдельно запускать процессы загрузки и выгрузки данных;
• Автоматическое выполнение обмена информацией не препятствует ручному обмену;
• Простота настройки (для стандартных конфигураций не надо даже создавать правила обмена;
• Достаточно единожды создать синхронизацию и объявить расписание ее выполнения.

Условия нашей задачи

На входе мы имеем две стандартных конфигурации базы данных:

1. Зарплата и управление персоналом (редакция 3.1.3);
2. Бухгалтерия сельскохозяйственного предприятия (редакция 3.0.52).

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

Если синхронизация будет настраиваться из «Бухгалтерии» в «ЗУП» должна быть активирован флажок «Синхронизация» и наоборот.

Где находятся настройки

В «Бухгалтерии» заходим в подсистему «Администрирование», в меню «Настройка» и находим пункт «Синхронизация данных» (Рис. 1)

Откроется окно настройки синхронизации (Рис. 2)

Рис. 2

Здесь мы можем:

1. Включить или отключить синхронизацию;
2. Запретить загрузку неактуальных данных;
3. Установить префикс для идентификации перенесенных данных;
4. Перейти к другим настройкам синхронизации.

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

Окно настроек синхронизации данных представлено на Рис. 3

Рис. 3

Рассмотрим его подробнее.

Окно настроек синхронизации

Начнем по порядку:

Отдельно хотелось бы заострить внимание читателя на окне «Регистрация изменений» (Рис. 5). В верхней части которого есть номера отправленного и принятых сообщений, после удачного обмена номера в базе-источнике и базе-приемнике должны совпадать. В некоторых случаях (синхронизация произошла с копией базы, сбои в работе) нумерация в базах нарушается. Исправить эту ситуацию можно простым щелчком на гиперссылке с номерами. Это действие позволяет вручную установить текущий номер отправленного и входящего сообщений (Рис. 6)

Рис. 6

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

На закладке «Настройки синхронизации данных» есть две команды:

• Настроить;
• Загрузить правила.

Запуск команды «Загрузить правила» открывает форму (Рис. 7)

Рис. 7

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

Остальные настройки происходят по щелчку по кнопке «Настроить» (Рис. 8).

Рис. 8

В первом открывшемся окне можно:

1. Открыть форму настройки сценария синхронизации;
2. Просмотреть события отправки и получения информации;
3. Определить дату, с которой будет происходить обмен;
4. Если учет ведется по нескольким организациям, можно указать, какие именно из них будут участвовать в обмене;
5. Определить параметры выгрузки проводок по зарплате: с детализацией по сотрудникам или без нее (сводно).

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

Подробнее стоит остановиться на параметрах подключения (Рис. 9)

Рис. 9

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

Нам необходимо:

• Определить путь к базе-приемнику;
• Задать параметры авторизации (в базе-приемнике должен быть создан пользователь с правами администратора);
• После проверки подключения можно считать, что наша настройка закончена.

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

Настройки расписания

И в конце пара слов про настройки расписания синхронизации, оно выполняется в соответствующей закладке окна (Рис. 3) и ничем не отличается от соответствующей формы настройки расписания прочих регламентных заданий.

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

В моём случае обмен настраивается между конфигурациями "Управление торговлей 11.2" (далее УТ) и "Бухгалтерия предприятия 3.0.43" (далее БП). Обмен односторонний, из УТ в БП. До обновления "Управление торговлей 11.1" на версию "11.2" обмен данными был настроен с помощью конфигурации "Конвертация данных 2.0". Однако после перехода на "11.2" в "Управление торговлей" появились ошибки при работе пользователей. Процедура обновления правил обмена была проведена, но результата это не дало. Отладчик показывал, что проблема в обмене данными. Было решено удалить настройку обмена данными в обеих конфигурациях и настроить заново.

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

Ошибка при вызове метода контекста (Проверить): Ошибка проверки данных XDTO:
Структура объекта "/БанковскийСчетКонтрагента/Банк" не соответствует типу: {http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1}КлючевыеСвойстваБанк
Проверка свойства "БИК":
форма: Элемент
имя: {http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1}БИК
тип:
Отсутствует обязательное свойство
Объект: ДоговорСКонтрагентом № ...

Для анализа ошибки нажал на пиктограмму "Состав отправляемых данных" и в списке зарегистрированных к отправке договоров контрагентов нашёл договор, по которому появилась ошибка. Открыл договор, запомнил банковский счёт контрагента, указанный в договоре. Затем перешёл к зарегистрированным к отправке банковским счетам. Оказалось, что нужного счёта нет в списке зарегистрированных. Я перепровёл проблемный банковский счёт и договор. После этого зарегистрировал вручную нужный банковский счёт.

Повторил попытку синхронизировать данные из УТ. На этот раз данные успешно выгрузились. В сетевой папке сформировался XML файл, содержащий данные для переноса из УТ в БП.

Следующий этап - загрузить данные из файла в Бухгалтерию предприятия. В конфигурации "Бухгалтерия предприятия" я нажал кнопку "Синхронизировать", открылась форма обработки с сообщением "Выполняется анализ данных". Чуть позже сообщение сменилось на "Выполняется выгрузка данных". При этом индикатор и счётчик показывали, что из БП выгружается более 80-ти тысяч объектов. Это меня смутило, ведь я указывал в настройках, что из БП ничего не должно выгружаться. Обработка выполнялась довольно долго и завершилась ошибкой:

Событие: Обмен данными
{ОбщийМодуль.ДлительныеОперации.Модуль(371)}: Аварийно завершился рабочий процесс фонового задания
ВызватьИсключение(ТекстОшибки);

Чтобы локализовать ошибку, попробовал изменять настройки синхронизации и вараанты работы базы БП. В итоге, когда я перевёл базу в файловый вариант, система отработала адекватно: открылась форма сопоставления двух баз. После сопоставления объектов начальная синхронизация прошла успешно. Затем я снова перевёл базу в клиент-серверный вариант.

При дальнейшей "обкатке" синхронизации, потребовалось внести кое-какие изменения в правила конвертации объектов. Настало время воспользоваться конфигурацией "Конвертация данных 3.0". Во встроенной справке конфигурации описан порядок работы. Также помогли статьи на сайте ИТС.

В итоге я загрузил в "Конвертация данных 3.0" следующие данные:

• Тексты общего модуля "МенеджерОбменаДаннымиЧерезУниверсальныйФормат" из двух баз
• Схема обеих баз
• Описание формата EnterpriseData (из одной любой базы)
• Правила конвертации

После загрузки открыл в "Конвертация данных 3.0" правила конвертации данных, объектов, свойств. Внёс необходимые мне правки. Затем воспользовался кнопкой "Выгрузить модуль менеджера обмена". Текст модуля скопировался в буфер обмена. Осталось только вставить его в конфигурацию.

Поэксперементировав с настройкой правил в "Конвертация данных 3.0", я для себя заключил, что в случае, когда вносимые правки незначительны, проще настраивать правила непосредственно в конфигурациях УТ и БП, в общем модуле "МенеджерОбменаДаннымиЧерезУниверсальныйФормат". Если же правки серъёзные, такие как, например, добавление нового объекта в обмен, тогда стоит воспользоваться конфигурацией "Конвертация данных 3.0".

Задачу по добавлению документа "Заказ поставщику" в план обмена я выполнял с помощью " Конвертация данных 3.0". В стандартном варианте УТ - БП этого документа в плане обмена нет.

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

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

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

• Синхронизация данных
• Универсальный формат EntepriseData
• Конвертация данных 3.0
• Конвертация данных 2.0
• Управление торговлей
• Бухгалтерия предприятия

И показываем, как с ее помощью СИЛЬНО упростить решение своих задач

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

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

Поэтому позовите коллег, им это будет тоже очень полезно.

Особенно, если они уже видели КД 3 и успели испугаться:)

Да, когда ее видишь в первый раз – там вообще ни фига не понятно.

Но на самом деле – все ОЧЕНЬ просто. Настолько просто, что вам потом даже скучно будет:)

Что конкретно в сегодняшних видео

Это 4 видео по обмену данными через универсальный формат обмена EnterpriseData .

Кроме того, мы покажем пример доработки типовых правил обмена в 1С:Конвертации данных 3.0

Общая длительность – 34 минуты . Содержание:

• Настройка обмена на примере 1С:Бухгалтерии 8 и 1C:ERP
• Как сделать загрузку типовых правил и универсального формата обмена в Конвертации Данных 3.0
• Перенос структуры метаданных в КД 3.0
• Как выполнить первый обмен данными
• Доработка правил конвертации
• Как загрузить новые правила без изменения конфигурации (без снятия с поддержки )

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

Если бы подобная задача решалась в Конвертации данных 2.0, то изменения пришлось бы вносить в правилах и источника, и приемника.

Данные видеоуроки актуальны для БСП редакции 2.3.2 (для любой сборки старше 2.3.2.43).

Если Вы используете более старшую версию БСП,0 сделайте «поправку» на изменившийся интерфейс и расширенную функциональность. Для этого самостоятельно повторите пример из видео.

Видео 1:
Загрузка правил обмена между типовыми конфигурациями в Конвертацию данных 3.0

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

• Загрузка в КД структуры формата обмена (
• Создание конвертации
• Выгрузка файлов правил из типовой конфигурации
• Выгрузка модуля менеджера обмена

Видео 2:
Доработка правил обмена в КД 3.0

В этом уроке мы покажем, как дозаполнить реквизиты объектов при загрузке данных.

Будет решена задача – при загрузке объектов из конфигурации-источника устанавливать комментарий “Загружено из БП 3.0”.

Для решения задачи потребуется внести изменения в правилах конвертации объектов , в событии “Перед записью полученных данных”.

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

Видео 3:
Настройка универсального обмена между типовыми конфигурациями

В этом уроке мы покажем, как настраивать новый обмен между типовыми.

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

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

Видео 4:
Перенос начальных остатков с помощью правил обмена

В уроке покажем типовой функционал переноса начальных остатков.

P.S.

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

Однако для стандартных обменов – стандартные методы и быстрее, и сильно проще.

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

P.P.S.

Мы хотим показать, что Конвертация Данных 3.0 – это не сложно.

Непривычно – да. Не все сразу понятно – да. Есть очень неоднозначные моменты – да.

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