10.06.2022

Требования к разработке драйверов подключаемого оборудования (версия 3.7)

Внимание! Данные требования устарели. Актуальные требования размещены в статье.

• Изменения в стандарте
• Введение
• Разработка драйвера для подключения оборудования локально к устройству пользователя
•     Общие требования к разрабатываемому драйверу и его архитектуре
•     Обязательные функции и методы, связанные с использованием драйвера подключаемого оборудования в системе
•     Описание методов, специфичных для типов подключаемого оборудования
  • Требования к разработке драйверов для электронных весов
  • Требования к разработке драйверов для электронных весов с печатью этикеток в режиме "OFFLINE"
  • Требования к разработке драйверов для дисплеев покупателя
  • Требования к разработке драйверов для терминалов сбора данных
  • Требования к разработке драйверов для ККТ с функцией передачи в ОФД
  • Требования к разработке драйверов для принтеров чеков
  • Требования к разработке драйверов для принтеров этикеток
  • Требования к разработке драйверов устройств ввода (сканеры штрихкода, считыватели магнитных карт и т.д.)
  • Требования к разработке драйверов для эквайринговых терминалов
  • Требования к разработке драйверов для RFID считывателей
•     Подключение драйверов, разработанных по стандарту «1С: Совместимо» к конфигурации БПО
  • Подготовка драйвера к загрузке в конфигурацию БПО
  • Загрузка подготовленного драйвера в конфигурацию БПО
  • Использование драйвера предварительно установленного на локальных компьютерах
• Подключение программно-аппаратных комплексов с помощью файлового обмена
• Подключение программно-аппаратных комплексов с помощью web-сервиса "EquipmentService"

Изменения в стандарте

Примечание. Устаревшие версии требований доступны в архиве.

Начиная с версии стандарта 3.3  в данном документе объединены требования к разработке драйверов подключаемого оборудования и требования к разработке драйверов мобильных устройств.
Для каждого типа оборудования указана возможность использования данного типа оборудования в мобильных приложениях и перечислены типы клиентов "1С:Предприятия".

В соответствии с данными требованиями фирма 1С выпускает два продукта:

• 1С:Библиотека подключаемого оборудования (начиная с версии 3.1.4)
  Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент.
• 1С:Библиотека подключаемого оборудования для мобильных приложений (начиная с версии 2.17)
  Поддержка: мобильное приложение.

Введение

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

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

Поддерживается взаимодействие с программно-аппаратными POS-системами (от англ. "Point of Sale" - "Точка продаж"), обеспечивающими розничные продажи.
Взаимодействие обеспечивается с помощью файлового обмена с помощью встроенного в библиотеку "1С:Библиотека подключаемого оборудования" модуля "1С: ККМ-Offline".

Библиотека поддерживает работу сторонних программно-аппаратных комплексов различного назначения с помощью Веб-сервиса оборудования. Для осуществления обмена необходимо опубликовать Веб-сервис "EquipmentService", входящий в состав библиотеки. Веб-сервис обрабатывает запросы на получение и обработку данных от программно-аппаратных комплексов и возвращает стандартный результат во внешний программно-аппаратный комплекс.  

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

Общую структуру документа можно разделить на две части: требования к разработке драйвера для подключения оборудования локально к устройству пользователя и подключение аппаратно-программных систем с помощью веб-сервиса оборудования.

Разработка драйвера для подключения оборудования локально к устройству пользователя

Оборудование подключается к системе с помощью драйвера, разработанного в соответствии с технологией создания внешних компонент. Технология определяет интерфейс взаимодействия между платформой 1С и драйвером. Реализация драйвера возможна с использованием стандартных компонентных объектов только для Windows (COM-интерфейс) и собственной технологии фирмы 1С – NativeAPI .

Разработка драйвера в технологии NativeAPI имеет ряд преимуществ. С помощью технологии можно создавать внешние компоненты, которые могут подключаться как в клиентском приложении, в том числе в тонком и web-клиенте, мобильном клиенте, мобильном приложении, так и на сервере "1С:Предприятия", разработать универсальные программные компоненты для Windows, Linux, Android и iOS.

Интерфейс внешней компоненты можно условно разделить на несколько частей:

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

1. Общие требования к разрабатываемому драйверу и его архитектуре

Разрабатываемый драйвер должен:

1. Быть разработан в виде внешней компоненты по технологии создания внешних компонент, приведенной в статье "Технология создания внешних компонент".
2. Внешняя компонента для работы с подключаемым оборудованием должна содержать только один объект, реализующий расширение встроенного языка, и возвращать методом «RegisterExtensionAs» имя расширения, совпадающее с второй частью ProgID компоненты. Пример: для компоненты с ProgID «AddIn.Scanner» функция должна возвращать «Scanner». Имя расширения не должно содержать пробелов и недопустимых символов (в соответствии с правилами формирования имен объектов "1С:Предприятия").
3. Обеспечить возможность реализации функционала в полном объеме (должны быть реализованы и работать все методы) для подключаемого типа оборудования. Если оборудованием данная функция не поддерживается, должно возвращаться "False", а в описании ошибки, возвращаемом методом "ПолучитьОшибку/GetLastError", содержится текст, что данная функция оборудованием не поддерживается.
4. Предоставлять русскоязычные и англоязычные названия методов (например ПолучитьОшибку() - GetLastError() и др.).
5. Поддерживать работу с несколькими экземплярами устройств, в рамках процедур в которых используется данное оборудование.
6. При возникновении ошибки в работе предоставлять подробное описание произошедшей ошибки, позволяющее пользователю понять причину ее возникновения и возможный способ устранения.
7. При возникновении внештатных ситуаций (некорректные действия пользователя, отсутствие запрашиваемого метода или функции, передача некорректных значений и др.) корректно обрабатывать их. Не должно быть аварийных завершений работы драйвера и прочих действий драйвера, которые могут привести к нарушению нормальной работы пользователя.
8. Принимать/возвращать и обрабатывать таблицы значений в виде XML документа (текст в формате XML с кодировкой UTF-8, передаваемый с помощью параметра типа STRING).
   Для упрощения обработки структур данных используются наименования атрибутов только на английском языке.
9. Обрабатывать метод SetLocale для локализации драйвера в соответствии с полученным кодом локализации и настраивать свое окружение (текстовые надписи, сообщения об ошибках и т.д.). Драйвер должен поддерживать локализированное окружение для локального кода региона и локализацию окружения на английском языке. Если полученный код локализации отличается от предусмотренного в драйвере, то драйвер должен настроить свое окружение на использование английского языка. Более подробно использование метода SetLocale описано в документе "Технология создания внешних компонент".

При разработке драйвера можно использовать несколько архитектурных решений:

• Однокомпонентный драйвер - Драйвер представляющий из себя один файл - внешнюю компоненту, и предназначенный для использования только с системой программ «1С:Предприятие». При разработке драйвера в виде одного файла все используемые run-time библиотеки и другие необходимые файлы должны статически включаться в драйвер, так как на устройстве пользователя их может не оказаться или они могут быть другой версии. Рекомендуемая технология для разработки данного драйвера - NativeAPI.
• Многокомпонентный драйвер - Драйвер, представляющий из себя сложный программно-аппаратный комплекс, предназначенный для использования как и с системой программ «1С:Предприятие», так с программными решениями сторонних производителей. Разрабатываемый драйвер состоит из двух частей:
  • Интеграционный компонент - промежуточный компонент для связи "1С Предприятия" с основной поставкой драйвера. Имеет интерфейс, разработанный в соответствии общими требованиями к драйверу и технологией разработки внешних компонент, но не реализует функционала драйвера подключаемого оборудования. Интеграционный компонент реализует функционал поиска установленной основной поставки драйвера, его инициализацию и переадресацию вызовов. Все используемые run-time библиотеки и другие необходимые файлы должны быть статически включены в компоненту.
  • Основная поставка драйвера - драйвер поставщика, реализованный по произвольной технологии и состоящий из произвольного набора файлов. Протокол взаимодействия драйвера с интеграционным копонентом не регламентируется данными требованиями. Поставка драйвера осуществляется посредством инсталляции из дистрибутива поставщика.

ВНИМАНИЕ: Для типа оборудования "Дисплей покупателя", "Устройства ввода", "Принтеры чеков", "Терминал сбора данных", "Электронные весы" допускается разработка драйвера в однокомпонентной архитектуре. Для других типов оборудования необходимо использовать многокомпонентную архитектуру!

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

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

Драйвер поддерживает два основных этапа работы с оборудованием в конфигурации:

• Регистрация и настройка оборудования
• Использование оборудования пользователем в процессе работы

Регистрация и настройка оборудования

1. Получение описания драйвера вызовом метода «ПолучитьОписание(GetDescription)».
2. Получение доступных параметров для настройки драйвера методом «ПолучитьПараметры(GetParameters)».
3. Построение формы настройки драйвера на основании списка доступных параметров.
4. Сохранение параметров настройки драйвера в базе данных конфигурации.

Использование оборудования пользователем в процессе работы

1. Инициализация устройства сохраненными в базе параметрами методом «УстановитьПараметр(SetParameter)».
2. Подключение оборудования с помощью метода «Подключить(Open)» с текущими значениями параметров, установленными вызовами метода «УстановитьПараметр(SetParameter)». Метод «Подключить(Open)» возвращает идентификатор подключенного экземпляра устройства.
3. Вызов обязательных функций и методов, специфичных для данного типа подключаемого оборудования, с использованием идентификатора подключенного экземпляра устройства.
4. Получение кода ошибки и описание ошибки методом «ПолучитьОшибку(GetLastError)» в случае ее возникновения.
5. Отключение устройства методом «Отключить(Close)» по идентификатору подключенного экземпляра устройства.

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

** - Версия требований – версия текущего документа (Версии 2.00 соответствует число 2000. Версии 2.4 соответствует число 2004. Текущей версии 3.7 соответствует число 3007.

ОписаниеДрайвера (DriverDescription)

Текст в формате XML, передаваемый с помощью параметра типа STRING. Содержит информацию о драйвере.

* - Обязательно только для многокомпонентных драйверов.
** - Обязательно только для типов оборудования: “ККТ“, “ЭквайринговыйТерминал“, “ВесыСПечатьюЭтикеток“. Для типа оборудования “ККТ“ рекомендуется включать ведение лога драйвера по умолчанию. Настройку уровня детализации логирования можно вывести в параметры драйвера. В лог файл рекомендуется включать информацию, полученную от 1С, - в частности, XML пакеты данных.

Пример XML описания драйвера :

<?xml version="1.0" encoding="UTF-8"?>
<DriverDescription 
      Name="Драйвер ККТ" 
      Description="Драйвер ККТ" 
      EquipmentType="ККТ" 
      IntegrationComponent="true" 
      MainDriverInstalled="true" 
      DriverVersion="1.1" 
      IntegrationComponentVersion="1.1" 
      DownloadURL="http://files.1с.ru/file.ZIP" 
      LogIsEnabled="true" 
      LogPath="C:\Users\drivers\"/>

ТаблицаПараметров (TableParameters)

Текст в формате XML, передаваемый с помощью параметра типа STRING. Содержит описание всех параметров драйвера и описание визуального интерфейса настройки драйвера.

Необходимые для работы параметры могут быть структурированы для вывода на форму конфигурации "1С:Предприятия" - распределены по закладкам и группам на закладке. Закладки и группы могут иметь наименования, которые отобразятся на форме. Для параметров могут быть заданы определенные значения, которые сформируют выпадающий список для выбора. Наконец, поля параметров, зависимых от других параметров, могут активироваться по необходимости.

Пример текстового XML описывающего параметры драйвера:

 <?xml version="1.0" encoding="UTF-8" ?>
 <Settings>
      <Page Caption="Параметры">    
      <Group Caption="Параметры подключения">
           <Parameter Name="Model" Caption="Модель" TypeValue="Number"/> 
           <Parameter Name="Port" Caption="Порт" TypeValue="Number" DefaultValue="0">
              <ChoiceList>
                  <Item Value="0">Клавиатура</Item>
                  <Item Value="1">COM1</Item>
                  <Item Value="2">COM2</Item>
               </ChoiceList>
           </Parameter>
           <Parameter Name="Parity" Caption="Четность" TypeValue="Boolean" DefaultValue="true"/>
           <Parameter Name="Speed" Caption="Скорость" TypeValue="Number" DefaultValue="1"/>
         </Group>
      </Page>
 </Settings>

В результате будет сформирована следующая форма для ввода параметров:

ТаблицаДействий (TableActions)

Текст в формате XML, передаваемый с помощью параметра типа STRING. Содержит описание дополнительных действий для настройки и управления драйвером в форме настройки оборудования, доступной администратору.
Данные действия будут отображаться пунктами меню в разделе "Функции", после пункта меню "Тест устройства" на форме настройки экземпляра подключаемого оборудования. При выборе определенного пункта меню будет вызван метод драйвера "ВыполнитьДополнительноеДействие" с параметром "ИмяДействия", соответствующий данному пункту меню. При выполнении данного действия драйвер может создавать дополнительные диалоговые окна в соответствии с документом "Технология создания внешних компонент".

Пример текстового XML, описывающего дополнительные действия:

 <?xml version="1.0" encoding="UTF-8" ?>
 <Actions>
      <Action Name="SettingLog" Caption="Параметры журналирования"/> 
 </Actions>

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

3. Описание методов, специфичных для типов подключаемого оборудования

3.1. Требования к разработке драйверов для электронных весов

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент, мобильное приложение.

Конфигурациями поддерживаются следующие возможности работы с весами on-line:

1. Ввод значения веса тары, используемой для упаковки взвешиваемого товара.
2. Получение значения веса товара за вычетом веса тары.

3.2. Требования к разработке драйверов для электронных весов с печатью этикеток в режиме "OFFLINE"

Поддержка: тонкий клиент, web-клиент, толстый клиент.

Работа с электронными весами с печатью этикеток заключается в выгрузке таблицы товаров. Таблица формируется на основе базы данных средствами конфигурации. Обработка выгрузки таблицы товаров в электронные весы должна предусматривать выгрузку несколькими итерациями путем последовательных вызовов метода «ВыгрузитьТовары (UploadGoods)» с пакетами данных определенного размера (например, по 100 записей) с дополнительным параметром, определяющим статус пакета ("first" - первый пакет,  "regular" - очередной, "last" - последний пакет).

* - Строка, определяющая статус пакета, имеет одно из значений: "first", "regular", "last".

ТаблицаТоваров (GoodsTable)

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Пример текстового XML, содержащий данные:

<?xml version="1.0" encoding="UTF-8"?>
 <Table>
    <Record PLU="1" Code="1003" Name="Яблоки Антоновка" Price="95,50" ShelfLife="7" IsWeightGoods="true"/>
    <Record PLU="2" Code="1023" Name="Салат Болгарский" Price="500,00" IsWeightGoods="true" 
            Description="Состав: свекла, морковь, ветчина, мясо, сыр, яйцо, лук репчатый, майонез" ShelfLife="5"/>
 </Table>

3.3. Требования к разработке драйверов для дисплеев покупателя

Поддержка: тонкий клиент, web-клиент, толстый клиент.

При оформлении документов продажи необходимая информация может отображаться на дисплее покупателя. Состав информации определяется в конфигурации.
Поддерживаются многострочные дисплеи и разбиение строк на области. Также поддерживается специализированный дисплей QR кода.

ПараметрыДисплеяПокупателя (CustomerDisplayOptions)

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Пример XML:

<?xml version="1.0" encoding="UTF-8"?>
<CustomerDisplayOptions 
      Columns="20" 
      Rows="2" 
      DisplayText="true" 
      DisplayQRCode="true"/>

3.4. Требования к разработке драйверов для терминалов сбора данных

Поддержка: тонкий клиент, web-клиент, толстый клиент.

Работа с терминалами сбора данных (ТСД) заключается в выгрузке таблицы товаров из конфигурации и загрузке данных об отобранных товарах.
Таблица для выгрузки в ТСД формируется на основе базы данных средствами конфигурации. Обработка выгрузки таблицы товаров в ТСД должна предусматривать выгрузку несколькими итерациями путем последовательных вызовов метода «ВыгрузитьТаблицу (UploadTable)» с пакетами данных определенного размера (например, по 100 записей) с дополнительным параметром, определяющим статус пакета ("first" - первый пакет,  "regular" - очередной, "last" - последний пакет).

В терминал загружается таблица товаров, и по ней отбираются товары. Предусматривается как частичная, так и полная выгрузка. Из терминала загружается таблица отобранных товаров.
Загрузка таблицы товаров производится однократно методом «ЗагрузитьТаблицу (DownloadTable)».

* - Строка, определяющая статус пакета, имеет одно из значений: "first", "regular", "last".  Если пакет один, то статусу пакета присваивается "last".

ТаблицаТоваров (GoodsTable)

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Пример текстового XML, содержащий данные: 

 
<?xml version="1.0" encoding="UTF-8"?> 
<Table FullLoad="true">
    <Record BarCode="4008110271538" Name="Блокнот для заметок" UnitOfMeasurement="Штуки" CharacteristicOfNomenclature="" 
                        SeriesOfNomenclature="" Quality="" Price="25,30" Quantity="7"/>="2900001355643" Name="Финики в банке" UnitOfMeasurement="Штуки" CharacteristicOfNomenclature="" 
            SeriesOfNomenclature="" Quality="Зеленые" Price="95,50" Quantity="7"/>
</Table>

ТаблицаЗагрузки (DownloadTable)

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Пример текстового XML, содержащий данные: 

<?xml version="1.0" encoding="UTF-8"?> 
<Table>
    <Record BarCode="4008110271538" Quantity="1" AlcoholExciseStamp="20N00001CKO68OY4QYX3T1731224004002671B1IEHLWKNFXFO8FPMERND09WMB8FYV7"/> 
    <Record BarCode="2900001355643" Quantity="2"/> 
</Table>

3.5. Требования к разработке драйверов для ККТ с функцией передачи в ОФД

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент, мобильное приложение.

ВНИМАНИЕ: Данный стандарт определяет требования к ККТ на основании формата фискальных документов версии по
приказу ФНС России от 14.09.2020 N ЕД-7-20/662@ "Об утверждении дополнительных реквизитов фискальных документов
и форматов фискальных документов, обязательных к использованию"

Проверка маркированного товара на ККТ реализована по следующему сценарию:

1. Проверка КМ осуществляется в рамках сессий.
   • Открытие новой сессии проверки марок на ККТ в явном виде осуществляется методом ОткрытьСессиюРегистрацииКМ().
   • Закрытие сессии проверки марок в явном виде осуществляется методом ЗакрытьСессиюРегистрацииКМ().
   • При фискализации чека методом СформироватьЧек() открытая ранее сессия проверки марок будет автоматически закрыта.
2. Запрос на проверку КМ на ККТ.
   • Формирование запроса на проверку КМ осуществляется методом ЗапросКМ().
   • Поле «MarkingCode» заполняется значением полной КМ в BASE64. Передача в BASE64 обусловлена тем, что в составе КМ могут присутствовать спецсимволы-разделители GS1.
   • Метод сразу же возвращает результаты локальной проверки КМ, формирует запрос в ОИСМ и переводит ККТ в режим ожидание получения ответа от ОИСМ.
   • Если нет необходимости ждать ответа от ОИСМ – в атрибутах метода ЗапросКМ() можно указать «WaitForResult= False», тогда статусы проверки КМ можно получить без ожидания ответа от ОИСМ.
3. Получение результата проверки КМ.
   • После формирования запроса на проверку КМ на ККТ нужно в обязательном порядке получить статут КМ методом ПолучитьРезультатыЗапросаКМ(). Даже есть запрос ЗапросКМ() выполнялся с атрибутом «WaitForResult= False».
   • Получение результата проверки происходит циклическим вызовом метода ПолучитьРезультатыЗапросаКМ(), пока он не вернет статус что результат получен или не может быть получен. Вызов метода должен осуществляться через временной интервал.
   • Пока метод в параметре «СтатусЗапроса» не вернет статус «0–результат получен» или «2–результат не может быть получен», другие операции невозможны.
4. Подтверждение КМ для последующего включения в чек.
   • После получения результата проверки КМ можно отобразить на экране статус проверки.
   • Если пользователь соглашается купить товар, маркированный проверяемой КМ – необходимо подтвердить методом ПодтвердитьКМ() с параметром «ТипПодтверждения=0».
   • Если пользователь отказывается от покупки товара, маркированного проверяемой КМ – необходимо отклонить методом ПодтвердитьКМ() с параметром «ТипПодтверждения=1».
5. Фискализация чека
   • Если КМ была проверена методом ЗапросКМ() и получен результат методом ПолучитьРезультатыЗапросаКМ(), и подтверждена к выбытию методом ПодтвердитьКМ() – такую КМ можно включать в фискальный чек.
   • Необходимо заполнить для фискальной строки атрибут «MarkingCode» - полной КМ в BASE64.
   • ККТ после фискализации чека формирует документ «Уведомление о реализации МТ» и отправляет его в ОФД.
6. Отмена чека
   • При отмене чека вызывается метод ЗакрытьСессиюРегистрацииКМ().  

Описание структуры TableParametersKKT

Текст в формате XML, передаваемый с помощью параметра типа STRING.

* Данные поля обязательны для фискализированных ФН.

Описание структуры ParametersFiscal

Текст в формате XML, передаваемый с помощью параметра типа STRING.
Данная таблица расширяет таблицу ТаблицаПараметровККТ (TableParametersKKT) следующими атрибутами:

* Данное поле обязательно при процедуре изменение параметров регистрации.

Описание структуры InputParameters

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Пример текстового XML:

 <?xml version="1.0" encoding="UTF-8"?>
 <InputParameters> 
	<Parameters CashierName="Иванов И.П." CashierINN="32456234523452"/>
 </InputParameters>

Описание структуры OutputParameters

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Описание структуры OperationCounters

Описание структуры DocumentOutputParameters

Пример текстового XML:

 <?xml version="1.0" encoding="UTF-8"?>
 <DocumentOutputParameters>
    <Parameters CheckNumber="5" ShiftClosingCheckNumber="1" ShiftNumber="2" AddressSiteInspections="www.nalog.ru" DateTime="2021-09-02T12:59:00" FiscalSign="2721313672"/>
 </DocumentOutputParameters>

Описание структуры CheckPackage

Текст в формате XML содержит описание передаваемого для формирования чека. Структура описывает параметры и последовательность формирования фискального чека.

* Данное поле обязательно только для чека коррекции. Передается только при вызове метода СформироватьЧекКоррекции (ProcessCorrectionCheck).
** В случае когда ставка "БЕЗ НДС", сумма НДС не заполняется. Сумма позиций без НДС рассчитывается по значениям атрибута "AmountWithDiscount" позиций со ставкой "БЕЗ НДС".

Пример текстового XML:

 <?xml version="1.0" encoding="UTF-8"?>
 <CheckPackage>
  <Parameters CashierName="Администратор" OperationType="1" TaxationSystem="0" SaleAddress="г.Москва, Дмитровское ш. д.9" SaleLocation="г.Москва, Дмитровское ш. д.9" CustomerEmail="" CustomerPhone="">
  <AgentData/>
  <VendorData/>
  <CustomerDetail/>
  <OperationalAttribute/>
  <IndustryAttribute/>
  </Parameters>
  <Positions>
   <FiscalString Name="Товарная позиция" Quantity="1" PriceWithDiscount="200" AmountWithDiscount="200" Department="0" VATRate="none" VATAmount="" PaymentMethod="4" CalculationSubject="1">
   <IndustryAttribute/>
   <AgentData/>
   <VendorData/>
   </FiscalString>
  </Positions>
 <Payments Cash="0" ElectronicPayment="200" PrePayment="0" PostPayment="0" Barter="0"/>
 </CheckPackage>

CorrectionData - Данные коррекции. XML Структура.

CustomerDetail - Cведения о покупателе (клиенте). XML Структура.

AgentData - Данные агента. XML Структура.

VendorData - Данные поставщика. XML Структура.

OperationalAttribute - Операционный реквизит. XML Структура.

IndustryAttribute - Отраслевой реквизит. XML Структура.

GoodCodeData - Код товарной номенклатуры. XML Структура. Значение всех элементов передаются в Base64.

RequestKM - Запрос КМ. XML Структура.

RequestKMResult - Результат запроса КМ. XML Структура.

Пример текстового XML:

 
<?xml version="1.0" encoding="UTF-8"?> 
<RequestKMResult Checking="True" CheckingResult="True"/>

ProcessingKMResult - Результат запроса о КМ в ОИСМ. XML Структура.

Пример текстового XML:

 
<?xml version="1.0" encoding="UTF-8"?> 
<ProcessingKMResult GUID="193DDFC8-15DF-4B14-AE84-1D5B741BC0AC" Result="True" StatusInfo="1" HandleCode="0"/>

UserAttribute - Дополнительный реквизит пользователя, XML Структура.

Описание структуры DocumentPackage

Текст в формате XML содержит описание текстового документа. Структура описывает последовательность формирования текстового документа.

Справочные таблицы

Системы налогообложения

Признаки способа расчета

Признаки предмета расчета

Признак агента

Признаки агента по предмету расчета

Код типа маркированной продукции

3.6. Требования к разработке драйверов для принтеров чеков

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент, мобильное приложение.

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

• Печать текстовых чеков (с возможностью печати штрихкодов);
• Открытие денежного ящика.

Алгоритм печати чека.

При подключении устройства командой "Подключить" драйвер инициализирует устройство печати, в том числе определяет кодировку для печати чеков.
При формировании чека конфигурация посылает команду "НапечататьТекстовыйДокумент" для печати текстового документа на принтере чеков. Содержимое печатаемого документа определяется структурой ДанныеДокумента.

Описание структуры DocumentPackage

Текст в формате XML содержит описание текстового документа. Структура описывает последовательность формирования текстового документа.

Пример текстового XML:

<?xml version="1.0" encoding="UTF-8"?>
<Document>
	<Positions>
		<TextString Text="Участие в дисконтной системе"/>
		<TextString Text="Дисконтная карта: 00002345"/>
		<Barcode BarcodeType="EAN13" Barcode="2000021262157"/>
	</Positions>
</Document>

3.7. Требования к разработке драйверов для принтеров этикеток

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент.

Работа с принтером печати этикеток заключается в выгрузке в драйвер сформированного пакета данных об этикетах. Пакет формируется средствами конфигурации и содержит описание форматирования шаблона этикетки и набора данных для формирования этикеток. Драйвер печати этикеток должен предусматривать обработку сформированного массива этикеток несколькими итерациями, путем последовательных вызовов метода «ПечатьЭтикеток (PrintLabels)» с пакетами данных определенного размера (например, по 100 этикеток) и с дополнительным параметром, определяющим статус пакета ("first" - первый пакет,  "regular" - очередной, "last" - последний пакет).

* - Строка, определяющая статус пакета, имеет одно из значений: "first", "regular", "last".

ТаблицаЭтикеток (LabelsTable)

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Структуру передаваемого пакета можно разделить на две составляющие секции:

• Formatting - Секция описания форматирования шаблона этикетки. Присутствует однократно и только в первом пакете и описывает поля (элементы "Text", "Barcode", "Image" и "UserData"), входящие в шаблон этикетки, и их форматирование.
• Labels - Секция набора данных для формирования этикеток. Секция присутствует в каждом пакете только один раз, и содержит данные для заполнения каждой их этикеток, которые необходимо распечатать.

Пример текстового XML, содержащий данные:  

 
<?xml version="1.0"?> 
 <Data> 
    <Formatting Width = "60" Height="40">
	<Text FieldName="Наименование" Left="1" Top="1" Width="55" Height="10" FontName="Tahoma" FontSize="8" FontStyle="Italic"/>
	<Text FieldName="Цена" Left="1" Top="11" Width="55" Height="10" FontName="Tahoma" FontSize="8" FontStyle="Bold Italic" Border="Left Top Right Bottom"/>
	<Barcode FieldName="Штрихкод" Type="EAN13" Left="1" Top="22" Height="10" PrintHRI="true" FontSize="8"/>
   </Formatting>
   <Labels>
        <Label Quantity="2">
	    <Record FieldName="Наименование" Value="Блокнот для заметок"/>
	    <Record FieldName="Цена" Value="43,5"/>
	    <Record FieldName="Штрихкод" Value="4008110271538"/>
        </Label>
        <Label Quantity="3">
	    <Record FieldName="Наименование" Value="Яблоки антоновка в банке"/>
            <Record FieldName="Цена" Value="78,5"/>
	    <Record FieldName="Штрихкод" Value="2900001355679"/> 
        </Label>
   </Labels> 
</Data> 

3.8. Требования к разработке драйверов устройств ввода (сканеры штрихкода, считыватели магнитных карт и т.д.)

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент, мобильное приложение.

Данные устройства реализуют функцию автоматического считывания закодированной различными способами информации и асинхронной передачи ее в конфигурацию "1С:Предприятия". Драйвера устройств такого типа не предусматривают специфических для оборудования методов, которые можно вызывать из конфигураций.

Работа с драйвером строится следующим образом:

1. При инициализации объекта компоненты ему передается указатель на интерфейс "1С:Предприятия", с помощью которого можно вызывать метод:
   HRESULT ExternalEvent(BSTR bstrWho, BSTR bstrWhat, BSTR bstrData)
2. При каждом успешном считывании кода сканером или считывателем драйвер должен вызывать метод HRESULT ExternalEvent(BSTR bstrWho, BSTR bstrWhat, BSTR bstrData).
3. Переданные данные размещаются в очереди сообщений. Сообщения из очереди обрабатываются только после обработки всех системных сообщений "1С:Предприятия". При переполнении очереди полученные сообщения игнорируются.

Описание методов, доступных для асинхронного вызова из драйвера*

* - Описание остальных функций, доступных для вызова из драйвера, см. в документе «Технология создания внешних компонент»
** - В параметре bstrWho драйвер передает уникальный идентификатор подключенного устройства.
*** - Параметр bstrWhat используется для поддержки событий различных типов.
Список возможных значение приведены в таблице:

3.9. Требования к разработке драйверов для эквайринговых терминалов

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент, мобильное приложение.

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

• Оплата картой
• Отмена платежа по карте
• Возврат платежа по карте
• Блокирование суммы на счете карты
• Списание заблокированной суммы со счета карты
• Отмена блокировки суммы на счете карты
• Оплата картой с выдачей наличных денежных средств
• Оплата с применением электронных сертификатом ФЭС НСПК
• Возврат с применением электронных сертификатом ФЭС НСПК
• Аварийная отмена операции
• Получение итогов дня по картам

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

Оплата картой

При необходимости оплатить покупку платежной картой Система вызывает метод "ОплатитьПлатежнойКартой", передавая во входном параметре сумму к оплате для списания с карты и номер считанной карты. Если считывание карты будет производиться на терминале (PIN-Pad’e) банка, то в параметре номера считанной карты передается пустая строка. Драйвер в ответ возвращает результат выполнения функции, код RRN, код авторизации и текст слип-чека. Текст слип-чека может быть самостоятельно распечатан терминалом на встроенном принтере или распечатан на ККТ (определяется методом ПараметрыТерминала). После выполнения функции в параметре номера считанной карты возвращается номер прочитанной на терминале (PIN-Pad’e) банка карты.

Отмена платежа по карте

Если происходит отмена платежа, то Система вызывает метод "ОтменитьПлатежПоПлатежнойКарте", передавая во входных параметрах сумму, которая была указана для списания с карты, номер считанной карты, код RRN операции, по которой совершается отмена, и код авторизации. Драйвер в ответ возвращает результат выполнения функции. Если считывание карты будет производиться на терминале (PIN-Pad’e) банка, то в параметре номера считанной карты передается пустая строка. После выполнения функции в параметре номера считанной карты возвращается номер прочитанной на терминале (PIN-Pad’e) банка карты.

Возврат платежа по карте

При возврате платежа Система вызывает метод "ВернутьПлатежПоПлатежнойКарте", передавая во входном параметре сумму к возврату на карту, номер считанной карты, код RRN операции, по которой совершается возврат, и код авторизации. Драйвер в ответ возвращает результат выполнения функции, а в выходные параметры записывает код RRN, код авторизации. Если считывание карты будет производиться на терминале (PIN-Pad’e) банка, то в параметре номера считанной карты передается пустая строка. После выполнения функции в параметре номера считанной карты возвращается номер прочитанной на терминале (PIN-Pad’e) банка карты.

Блокирование суммы на счете карты

При необходимости заблокировать сумму на счете платежной карты Система вызывает метод "ПреавторизацияПоПлатежнойКарте", передавая во входном параметре сумму для блокировки и номер считанной карты. Если считывание карты будет производиться на терминале (PIN-Pad’e) банка, то в параметре номера считанной карты передается пустая строка. Драйвер в ответ возвращает результат выполнения функции, код RRN, код авторизации и текст слип-чека. Текст слип-чека может быть самостоятельно распечатан терминалом на встроенном принтере или распечатан на ККТ (определяется методом ПараметрыТерминала). После выполнения функции в параметре номера считанной карты возвращается номер прочитанной на терминале (PIN-Pad’e) банка карты.

Списание заблокированной суммы со счета карты

При необходимости списания заблокированной суммы со счета платежной карты Система вызывает метод "ЗавершитьПреавторизациюПоПлатежнойКарте", передавая во входном параметре сумму для списания с карты, номер считанной карты, код RRN операции блокировки и код авторизации. Если считывание карты будет производиться на терминале (PIN-Pad’e) банка, то в параметре номера считанной карты передается пустая строка. Драйвер в ответ возвращает результат выполнения функции, код RRN, код авторизации и текст слип-чека. Текст слип-чека может быть самостоятельно распечатан терминалом на встроенном принтере или распечатан на ФР (определяется методом ПараметрыТерминала). После выполнения функции в параметре номера считанной карты возвращается номер прочитанной на терминале (PIN-Pad’e) банка карты.

Отмена блокировки суммы на счете карты

Для отмены блокирования суммы на счете платежной карты Система вызывает метод "ОтменитьПреавторизациюПоПлатежнойКарте", передавая во входном параметре сумму для списания с карты, номер считанной карты, код RRN операции блокировки и код авторизации. Если считывание карты будет производиться на терминале (PIN-Pad’e) банка, то в параметре номера считанной карты передается пустая строка. Драйвер в ответ возвращает результат выполнения функции, код RRN, код авторизации и текст слип-чека. Текст слип-чека может быть самостоятельно распечатан терминалом на встроенном принтере или распечатан на ФР (определяется методом ПараметрыТерминала). После выполнения функции в параметре номера считанной карты возвращается номер прочитанной на терминале (PIN-Pad’e) банка карты.

Оплата c электронным сертификатом

Метод "ОплатитьЭлектроннымСертификатом" осуществляет оплату с применением электронного сертификата ФЭС НСПК.

Возврат c электронным сертификатом

Метод "ВернутьЭлектроннымСертификатом" осуществляет возврат оплаты с применением электронного сертификата ФЭС НСПК.

Оплата по карте с выдачей наличных

Метод "ОплатитьПлатежнойКартойCВыдачейНаличных" осуществляет операцию оплату по карте с выдачей наличных денежных средств.
Операция выдачи наличных не является самостоятельной операцией и сопровождается обязательной оплатой покупки по карте. 

Аварийная отмена операции

Если операция по платежной карте прошла успешно и слип-чек должен быть распечатан на ФР (определяется методом ПараметрыТерминала), но возникла ошибка печати, то операция по карте должна быть аварийно отменена.

Получение итогов дня по картам

Для получения текста отчета Система вызывает метод "ИтогиДняПоКартам". Драйвер возвращает результат выполнения функции и текст отчета. 

* - Если информация, считанная с карты, передается в эквайринговую систему из конфигурации "1С:Предприятия", содержание этого поля должно отвечать требованиям конкретной эквайринговой системы.
** - Если при печати необходимо формировать несколько отдельных документов, в тексте для их разделения должна присутствовать строка "[отрезка]" или "[cut]". 
          Текст не должен содержать управляющие символы с кодами 1-8, 11-12, 14-31.

ПараметрыТерминала (TerminalParameters)

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Пример XML:

<?xml version="1.0" encoding="UTF-8"?>
<TerminalParameters 
      PrintSlipOnTerminal="true" 
      ShortSlip="true" 
      CashWithdrawal="true" 
      ElectronicCertificates="true"/>

3.10. Требования к разработке драйверов для RFID считывателей

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент, мобильное приложение.

Работа с RFID считывателями в "1С:Предприятие" осуществляется в асинхронном режиме. Открытие новой сессии считывания меток осуществляется командой «ОткрытьСессиюRFID». О всех новых метках попадающих в зону действия антенны считывателя передаются уведомление в "1С:Предприятие" внешним событием. Внешним событием передается идентификатор пакета, содержащий данные меток. После обработки внешнего события "1С:Предприятие" получает данные меток вызовом метода «ПолучитьДанныеМетокRFID» по идентификатору пакета (вызов данного метода служит подтверждением, что данные были доставлены).
Закрытие сессии считывания меток осуществляется командой «ЗакрытьСессиюRFID». Запись данных в метку осуществляется в рамках открытой сессии методом «ЗаписатьДанныеВМеткуRFID». Метка идентифицируется по TID и EPC. В метод передаются данные для записи и необходимый банк памяти (EPC или USERMEMORY), куда будут записываться данные.

ТаблицаМеток (TagsTable)

Текст в формате XML, передаваемый с помощью параметра типа STRING.

Пример текстового XML, содержащий данные:

 
<?xml version="1.0" encoding="UTF-8"?>
 <Table>
    <Tag TID="E28011002000589616B408A1" EPC="3074367C34001E880A6D6168" USER=""/>
    <Tag TID="E28011002000589216B308A1" EPC="30751BD15C35BC0508B59F22" USER=""/>
 </Table>

1. При инициализации объекта компоненты ему передается указатель на интерфейс "1С:Предприятия", с помощью которого можно вызывать метод:
   HRESULT ExternalEvent(BSTR bstrWho, BSTR bstrWhat, BSTR bstrData)
2. При попадании новых меток в зону действия антенны считывателя - драйвер формирует пакет с данными меток и передает уведомление в "1С:Предприятие" внешним событием. Во внешнем событии передается идентификатор пакета, содержащего данные. Внешнее событие формируется посредством вызова метода HRESULT ExternalEvent(BSTR bstrWho, BSTR bstrWhat, BSTR bstrData).
3. Переданные данные размещаются в очереди сообщений. Сообщения из очереди обрабатываются только после обработки всех системных сообщений "1С:Предприятия". При переполнении очереди полученные сообщения игнорируются.

Описание методов, доступных для асинхронного вызова из драйвера*

* - Описание остальных функций, доступных для вызова из драйвера, см. в документе «Технология создания внешних компонент»
** - В параметре bstrWho драйвер передает уникальный идентификатор подключенного устройства.
*** - Параметр bstrWhat используется для поддержки событий различных типов. Для RFID считывателей должен содержать строку «RFID».
 В случае ошибки этот параметр должен содержать значение "ОшибкаДрайвера" («DriverError»). В этом случае параметр bstrData должен содержать описание ошибки.

4. Подключение драйверов, разработанных по стандарту "1С: Совместимо» к конфигурации БПО"

Поддержка: тонкий клиент, толстый клиент.

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

Предоставляется возможность:

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

* -Только для драйверов, разработанных по COM технологии. В данном режиме не поддерживается работа в web-клиенте и Linux клиенте.

4.1. Подготовка драйвера к загрузке в конфигурацию БПО

Подготовка однокомпонентного драйвера или интеграционной библиотеки, поставляемых в виде архива внешней компоненты

Подготовка драйвера, поставляемого в виде архива внешней компоненты для загрузки в конфигурацию БПО, осуществляется согласно разделу "Подготовка внешних компонент для загрузки в конфигурацию" документа "Технология создания внешних компонент". Кроме того, в архиве должен присутствовать XML файл c именем "INFO.XML", содержащий информацию для загрузки драйвера.

XML файл должен иметь следующую структуру:

Пример файла "INFO.XML", описывающего информацию о драйвере:

<?xml version="1.0" encoding="UTF-8"?>
<drivers>
	<component progid="AddIn.EmulatorFP1C" type="ФискальныйРегистратор" name="1C: Эмулятор фискального регистратора" version="1.0.21.1"/>
</drivers>

4.2. Загрузка подготовленного драйвера в конфигурацию БПО

Поддержка: тонкий клиент, толстый клиент.

Для загрузки подготовленного драйвера необходимо перейти в раздел "Подключаемое оборудование\Драйверы оборудования".
В форме списка драйверов нажать "Подключить новый\Загрузить в информационную базу" и в отрывшемся диалоге выбора файла выбрать подготовленный для загрузки файл драйвера.
После открытия формы загружаемого драйвера необходимо проверить корректность заполнения информации о драйвере (поля: Тип оборудования, Наименование, Идентификатор объекта) и нажать кнопку "Записать и закрыть".

4.3. Использование драйвера, предварительно установленного на локальном компьютере

Для подключения драйвера, предварительного установленного на локальном компьютере, необходимо перейти в раздел "Подключаемое оборудование\Драйверы оборудования".
В форме списка драйверов нажать "Подключить новый\Установленный на локальный компьютере, и в открывшейся форме создаваемого драйвера ввести необходимые параметры драйвера в поля: Тип оборудования, Наименование, Идентификатор объекта.
После заполнения необходимых данных нажать кнопку "Записать и закрыть". Данная возможность предусмотрена только для драйверов разработанных по COM технологии.
В данном режиме не поддерживается работа в web клиенте и Linux клиенте.

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

Поддержка: тонкий клиент, web-клиент, мобильный клиент, толстый клиент.

Тип офлайн оборудования: ККМ

Работа с программно-аппаратными POS-системами (активными системными контрольно-кассовыми машинами) в режиме "Офлайн" заключается в файловом обмене информацией. В POS-систему из конфигурации выгружаются данные (настройки, прайс-лист, заказы), в конце рабочего дня в конфигурацию загружаются данные о продажах (формируются в разрезе кассовых смен с детализацией по чекам), зарегистрированных POS-системой в течение смены.

Выгружаемые на ККМ данные формируются на основе данных информационной базы средствами конфигурации (драйвер "1С:Офлайн оборудование"). Имена файлов и пути размещения задаются пользовательскими настройками.

Список команд, поддерживаемых драйвером "1С:Офлайн оборудование" библиотеки подключаемого оборудования

ImportData.xml

Данные выгрузки (ExportData)

Секция настроек (Settings)

Секция видов электронной оплаты (ElectronicPaymentOptions)

Секция прайс-листа (PriceList)

Список алкогольных реквизитов (Alcohol)

Секция характеристик товаров (Characteristics)

Секция упаковок товара (Packs)

Условие наличия атрибутов "Code", "Barcodes", "Price", "Balance"

Таблица товаров имеет древовидную структуру. Товар может иметь иметь набор характеристик и набор упаковок.
Упаковки могут быть описаны как в секции товаров, так и в секции характеристик в случае, если учет товаров ведется в разрезе характеристик.
Атрибуты "Code", "Barcodes", "Price", "Balance" указываются для последнего (нижнего) уровня иерархии.

Например, для товара "Майка дет." вида "Одежда" необходимо вводить характеристику "Размер". Товар может продаваться как упаковкой по 3 шт., так и поштучно.
В этом случае формируются записи во всех трех секциях, код присваивается записям: "Майка дет."+"р-р. 22" в секции "Характеристики"
и для "Майка дет."+"р-р. 22"+"Уп." в секции "Упаковки".

* обязательный атрибут/секция
** может присутствовать, но не обязательно
- атрибут/секция должны отсутствовать

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

Секция единиц измерения (Units)

Секция штрихкодов (Barcodes)

Секция данных агентов (AgentsData)

Секция данных поставщиков (VendorsData)

Секция заказов (Orders)

Секция товаров заказа (Goods)

Данные для загрузки (ImportData)

Секция отчетов о продажах (SaleReports) Элемент SaleReport

Секция списка товаров чека (Goods)

Секция документов вскрытия алкогольной тары (AlcoholTareOpenings)

Общие таблицы

Секция оплат (Payments)

Секция дополнительных реквизитов (Extensions)

Подключение программно-аппаратных комплексов с помощью web-сервиса "EquipmentService"

Поддержка: тонкий клиент, web-клиент, толстый клиент.

Библиотека поддерживает обмен со сторонними программно-аппаратными комплексами различного назначения с помощью web-сервиса.
Для осуществления обмена необходимо опубликовать web-сервис "EquipmentService", входящий в состав библиотеки. 

Тип офлайн оборудования: Прайс-чекер

Требования поддержки методов:

Методы web-сервиса EquipmentService

Метод PostDocs

Метод GetDocs

Пакет прайс-листа (PriceListPackage)

Пример текстового XML:

<?xml version="1.0" encoding="UTF-8"?>
<PriceListPackage xmlns="http://www.1c.ru/EquipmentService/2.0.0.3" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" PackageTotal="2" PackageNumber="1">
    <IsFormed>true</IsFormed>
    <PriceList>
        ...
    </PriceList>
</PriceListPackage>

Секция отчетов прайс-чекера (PriceCheckerReports)

Элемент PriceCheckerReport:

Пример текстового XML:

<?xml version="1.0" encoding="UTF-8"?>
<PriceCheckerReports xmlns="http://www.1c.ru/EquipmentService/2.0.0.3" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <PriceCheckerReport Date="2017-09-11T12:00:00" Number="505" UUID="986cb877-1272-4d15-ada7-692473a40717">
        <Goods>
            <Good Code="100" Barcode="2100020307795" GoodUUID="1918351e-9327-445e-a648-893700731916"/>
        </Goods>
    </PriceCheckerReport>
</PriceCheckerReports>

Ответ отправки документа (PostDocsResponse)

Пример текстового XML:

<?xml version="1.0" encoding="UTF-8"?>
<PostDocsResponse xmlns="http://www.1c.ru/EquipmentService/2.0.0.3" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <IsSuccess>true</IsSuccess>
    <Description>Данные успешно загружены</Description>
</PostDocsResponse>