Почему после синхронизации 1С:Заказы с УТ 11 мобильное приложение пустое?

← На главную

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

Анализ проблемы: пустые пакеты обмена и теги ObjectDeletion

Проанализируем структуру XML-сообщений, которые формирует база 1С:УТ для мобильного приложения. При просмотре исходящего файла обмена по клиентам можно обнаружить следующую картину:


<v8msg:Body>
    <ObjectDeletion xmlns="http://v8.1c.ru/8.1/data/enterprise" ...>
        <Ref xmlns:d4p1="http://v8.1c.ru/8.1/data/enterprise/current-config" xsi:type="d4p1:CatalogRef.Партнеры">d0152557-9fa0-11e6-bbe5-001cf0d33b48</Ref>
    </ObjectDeletion>
    <ObjectDeletion ...>
        <Ref ... xsi:type="d4p1:CatalogRef.Партнеры">d0152558-9fa0-11e6-bbe5-001cf0d33b48</Ref>
    </ObjectDeletion>
</v8msg:Body>

В то же время в сообщениях по ценам и остаткам тело пакета <v8msg:Body/> оказывается полностью пустым. Выясним причину такого поведения механизма планов обмена.

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

Взаимосвязь видов цен, соглашений с клиентами и схемы выгрузки

Правила выборки клиентов заложены в макете компоновки данных СхемаВыгрузкиПартнеров плана обмена МобильноеПриложениеЗаказыКлиентов. Поведение алгоритма строится на следующих правилах:

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

Решение проблемы без доработки конфигурации

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

Перейдем в раздел НСИ и администрирование → Настройка НСИ и разделов → Продажи → Оптовые продажи и включим функциональную опцию Использование соглашений с клиентами.
Откроем справочник Типовые соглашения с клиентами (раздел Продажи) и создадим новое соглашение.
В соглашении укажем статус Действует и выберем нужный Вид цены, с которым должен работать мобильный агент. При этом не указываем конкретный сегмент партнеров, чтобы действие соглашения автоматически распространялось на всю клиентскую базу.
Выполним перерегистрацию данных для плана обмена МобильноеПриложениеЗаказыКлиентов. Для этого используем типовую обработку Регистрация изменений для обмена данными, зарегистрировав заново справочники Партнеры, Номенклатура и цены.
Повторим сеанс синхронизации на мобильном устройстве. Клиенты и цены успешно загрузятся в мобильную базу.

Особенности проверки данных после переноса из 1С:Предприятия 7.7

Если информационная база заполнялась переносом остатков и справочников из конфигураций версии 7.7 (например, «Торговля и Склад 7.7»), обратим внимание на корректность заполнения реквизитов справочника Партнеры:

Признак клиента: в запросе выгрузки накладывается условие Клиент = Истина. При переносе из 7.7, где не было разделения на партнеров и контрагентов, данный флаг мог оказаться незаполненным.
Статус партнера: партнер должен быть активен, не иметь пометки на удаление и флага ПрекратитьОбслуживание.
Закрепление менеджера: если мобильный узел настраивается под конкретного торгового представителя, схема обмена может фильтровать клиентов по реквизиту ОсновнойМенеджер.

Ошибка сериализации: «Отсутствует отображение для типа 'УправляемаяФорма'»

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


{ОбщийМодуль.ОбменДаннымиМобильноеПриложениеКлиент.Модуль(37)}: Ошибка при вызове метода контекста (ОткрытьФорму)
    ОткрытьФорму("ОбщаяФорма.ФормаОбмена", ПараметрыФормы, ВладелецФормы);
по причине:
Ошибка преобразования данных XDTO:
Ошибка отображения типов:
Отсутствует отображение для типа 'УправляемаяФорма'

Выясним причину ошибки: метод ОткрытьФорму передает структуру ПараметрыФормы на сервер в обработчик ПриСозданииНаСервере. Если в эту структуру разработчиком было передано свойство, содержащее контекст клиентской формы (например, ссылка на ЭтаФорма или элементы интерфейса), сериализатор XDTO не может преобразовать интерфейсный объект платформы в данные XDTO.

Для исправления необходимо проверить состав структуры ПараметрыФормы перед вызовом. В параметрах формы допустимо передавать исключительно сериализуемые типы: примитивные типы (число, строка, дата, булево), ссылки на объекты базы данных (СправочникСсылка, ДокументСсылка), а также структуры и массивы, состоящие из этих типов данных.

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

В плане обмена МобильноеПриложениеЗаказыКлиентов стандартный реквизит Код узла имеет фиксированную длину — всего 2 символа. Это не является ошибкой конфигурации. Код узла в данном сценарии выполняет роль внутреннего короткого номера. Фактическая идентификация конкретного мобильного устройства выполняется через уникальный строковый идентификатор (GUID мобильного приложения), который хранится в реквизитах узла, поэтому расширять длину реквизита Код не требуется.